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Avant-propos 



UML, une evolution majeure dans le domaine des methodes 

UML compte deja une dizaine d'annees d'existence. A l'echelle d'un courant 
methodologique, c'est encore une duree relativement courte puisque Ton estime 
qu'un cycle de developpement d'une methode de cette envergure s'etale sur une 
periode de vingt a trente ans, ce qui a ete le cas par exemple pour Merise. 

Mais l'acceleration du renouvellement des technologies conjuguee avec la pres- 
sion economique et concurrentielle qui s'exerce sur les entreprises, obligent les 
acteurs du monde informatique a produire des solutions de plus en plus rapidement 
dans un contexte d'amelioration continue de la qualite et de la performance des sys- 
temes d'information. 

Notons aussi qu'Internet a ete un vecteur favorisant le developpement de tres 
nombreuses applications dont une grande partie utilise des solutions a base de lan- 
gage de programmation objet comme Java, C++ ou C#. 

UML a apporte tout naturellement le support methodologique qui manquait a 
tous les concepteurs et developpeurs qui voulaient formaliser l'analyse et la concep- 
tion technique de leur logiciel. 

UML s'est done imposee en tant que langage graphique de modelisation puisque 
non seulement ce langage repond a un veritable besoin mais en outre il est devenu 
un standard de fait puisqu'il s'appuie sur une norme tres structurante. 

Rendons tout de meme hommage aux trois peres fondateurs d'UML que sont 
James Rumbaugh, Ivarjacobson et Grady Booch qui ont ete des le debut des 
annees 90 des references dans le monde des methodes de developpement objets. Les 
ouvrages qu'ils ont ecrits a l'epoque sont la pour en temoigner : [Rumbaugh 1991], 
[Boochl994] et [Jacobsonl992]. 
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C'est grace a un premier niveau de travail de fond mene en commun par ces trois 
comperes qu'est nee en 1995 la methode dite unifiee qui a ete ensuite consacree par 
POMG (Object Management Group) en 1997 avec la diffusion de la premiere version 
de la norme : UMLV1.1. 

Precisons aussi que les trois auteurs a l'origine d'UML ont poursuivi leur mission 
d'explication et d'illustration des differentes versions successives d'UML en publiant 
des ouvrages de reference comme [Jacobson2000b] et [Rumbaugh2004]. 

II nous semble important de souligner le role majeur joue par l'OMG. En effet, 
cet organisme international de normalisation a en charge non seulement la norme 
UML mais aussi d'autres reflexions methodologiques comme l'approche MDA 
(Model Driven Architecture) qui pousse encore plus loin les limites de l'automatisa- 
tion de la production du logiciel. 

Ainsi nous pouvons imaginer que nous arriverons bien un jour a disposer d'une 
methode de conception et de developpement standardised couvrant tout le cycle de 
fabrication d'un logiciel en permettant une production fortement automatisee de la 
programmation. 

Mais soyons realistes, cela demandera a notre avis probablement plusieurs decen- 
nies etant donne les difficultes qui restent a traiter et la complexite des niveaux 
d' abstraction qu'il faut arriver a modeliser. 

C'est l'occasion pour nous de lancer un petit avertissement aux concepteurs 
d'UML travaillant a l'OMG pour leur dire que certes l'objectif vise represente un 
enorme challenge pour toute la profession informatique, mais cela ne doit pas se tra- 
duire par une plus grande lourdeur et complexite du contenu de cette norme. En 
effet, c'est le ressenti que nous commengons a avoir en observant les versions succes- 
sives de la norme qui se caracterise aujourd'hui par plusieurs centaines de pages a lire 
et un nombre sans cesse croissant de concepts a assimiler associes a une representa- 
tion graphique qui devient aussi de plus en plus dense. 

Positionnement de I'ouvrage 

Notre etude des nombreux ouvrages deja publies sur UML 2, nous a permis de cons- 
tater qu'il en existait deja un certain nombre qui s'etait attache a une presentation 
relativement exhaustive et detaillee de la norme, comme par exemple dans 
[Muller2000] et [Fowler2004a] ou encore d'autres plus synthetiques comme 
[Scott2004], [Fowler2004b], [Barbier2005] et [Blaha2002]. 

Cependant, nous n'avons pas trouve de livres traitant a la fois l'aspect norma- 
tif d'UML 2 et la demarche d'elaboration des diagrammes couvrant l'analyse et la 
conception des systemes d'information. 

Nous avons done decide de repondre a ce besoin en essayant de traiter le plus 
efficacement possible les treize diagrammes d'UML 2 conformement a la norme et 
en accompagnant le lecteur dans un apprentissage progressif fonde sur de nombreux 
exemples, des exercices corriges et de veritables etudes de cas se rapprochant de pro- 
jets reels d'entreprise. 
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Nous proposons done dans un meme ouvrage d'une part l'aspect theorique des 
concepts d'UML 2 et leur representation graphique et d'autre part une demarche de 
mise en ceuvre illustree par des fiches guides pour les activites d'analyse et de con- 
ception a mener dans le cadre des developpements des systemes d'information (SI). 

En resume nous nous sommes fixe trois objectifs en realisant ce livre : 

• presenter les treize diagrammes d'UML 2 en essayant de concilier au mieux le 
respect strict de la norme avec une application centree sur les systemes 
d'information des entreprises. 

• illustrer la modelisation a l'aide des diagrammes d'UML 2 en s'appuyant sur 
des exemples et des exercices adaptes au contexte professionnel done aux 
attentes des concepteurs et developpeurs d' application. 

• proposer une demarche de mise en ceuvre d'UML 2 qui est fondee sur les 
processus standard du developpement iteratif et incremental et qui prenne en 
compte notre propre experience de praticiens de la methode. Cette demarche 
fait l'objet d'une description precise des activites avec notamment des fiches 
guides et une mise en application dans deux etudes de cas consequentes. 

Notre double competence de professionnel de la conception et du developpe- 
ment des systemes d'information en entreprise, et d'enseignant universitaire dans le 
domaine des methodes des SI nous a permis de faire beneficier l'ouvrage de notre 
grande pratique (dix annees) d'UML, et de l'experience tiree de nombreuses annees 
d'enseignements d'UML dispenses en milieu universitaire (MIAGE, MASTER, 
IUT, BTS...). 

En tant qu'enseignant d'UML nous avons pu, au fil des annees, affiner une 
demarche progressive d'apprentissage. C'est ainsi que pour les points delicats, nous 
avons toujours recherche une approche pragmatique s'appuyant sur des exemples 
pour accompagner la presentation theorique des concepts. 

En tant que professionnel, les enseignements d'une longue experience de la pra- 
tique des methodes aupres des equipes de developpement de projets ont ete particu- 
lierement precieux. De plus, le point de vue des utilisateurs a ete aussi un indicateur 
pertinent pour ajuster au mieux la pratique de ces methodes. 

Enfin nous restons intimement convaincus que l'expose theorique d'une 
methode doit etre reduit a l'essentiel et qu'au contraire une large place doit etre don- 
nee a l'application ; c'est ainsi qu'en matiere d'apprentissage d'une methode, il faut 
bien entendu apprendre pour pratiquer mais aussi et peut-etre plus que dans 
n'importe quel autre domaine : pratiquer pour mieux apprendre. 

Organisation de l'ouvrage 

L'ouvrage est structure en six chapitres : 

• Le chapitre 1 decrit les concepts de l'approche objet et propose une premiere 
presentation d'UML 2 en mettant l'accent sur les dernieres evolutions. 
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• Le chapitre 2 traite les six diagrammes structurels : diagramme de classe, 
diagramme d'objet, diagramme de composant, diagramme de deploiement, 
diagramme de paquetage et diagramme de structure composite. 

• Le chapitre 3 est lui consacre aux sept diagrammes comportementaux : 
diagramme des cas d'utilisation, diagramme d'activite, diagramme d'etat-tran- 
sition, diagramme de sequence, diagramme de communication, diagramme 
global d'interaction et diagramme de temps. 

Des exemples et exercices corriges sont associes a la presentation de la plupart des 
1 3 diagrammes. Nous avons aussi utilise, en tant que fil conducteur, un meme exercice 
« Locagite » pour les diagrammes les plus structurants (classe, cas d'utilisation et sequence). 

• Le chapitre 4 porte sur la demarche que nous proposons de mettre en ceuvre 
avec UML 2 en vue de traiter l'analyse et la conception de systeme d'informa- 
tion. Cette demarche prend appui sur le processus unifie UP (Unified Process) 
et integre le fruit de l'experience des auteurs dans la conduite de projets reels 
menes en entreprise. 

Nous avons privilegie une presentation sous forme de « fiches guides » pour 
couvrir la demarche d'analyse et de conception. 

• Les chapitres 5 et 6 sont consacres aux etudes de cas afin d'illustrer, sur des 
sujets plus consequents que de simples exercices, le langage de formalisation 
d'UML 2 d'une part et l'application de la demarche proposee dans cet ouvrage 
d'autre part. 

La premiere etude de cas (chapitre 5) est essentiellement dediee a l'etape 
d'analyse, tandis que la seconde (chapitre 6) couvre les etapes d'analyse et de 
conception. 



En resume, le lecteur pourra tout d'abord acquerir les connaissances necessaires a I'appren- 
tissage d'UML 2 (chapitres 1 a 3) et ensuite s'exercer a la mise en pratique grace a la demar- 
che proposee et aux deux etudes de cas couvrant I'ensemble des phases d'analyse et de 
conception (chapitres 4 a 6). 



' s'adresse ce livre ? 

Cet ouvrage de synthese sur les concepts, la representation graphique des 
diagrammes d'UML 2 et la mise en ceuvre guidee en analyse et conception s'adresse : 

• aux etudiants de premier et second cycle universitaire qui veulent s'initier a 
UML 2 et maitriser tous les concepts ; 

• a tous ceux qui connaissent deja UML et qui desirent comprendre les change - 
ments apportes par UML 2 ; 

• a tous les professionnels, concepteurs et developpeurs, qui souhaitent mieux 
maitriser UML 2 et acquerir une demarche pratique de mise en ceuvre. 
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Concepts de I'approche objet 
et presentation d'UML 2 



1.1 CONCEPTS DE L APPROCHE OBJET 

Aujourd'hui l'approche objet occupe une place preponderante dans le genie logiciel. 
En effet, ces dernieres annees nous avons assiste tout d'abord a une utilisation plus 
large des langages de programmation objet de reference comme C++, C# et Java et 
ensuite a l'introduction des concepts objet dans d'autres langages comme par 
exemple VB.NET, Perl et meme Cobol. Le developpement tres important d'applica- 
tions liees a Internet constitue une des principales explications de ce phenomene 
sans precedent alors que Ton aurait pu s'attendre a un demarrage plus precoce de ce 
changement compte tenu de l'existence des le debut des annees 80 des premiers 
langages objet tel que C+ + . 

A notre avis les deux evenements majeurs qui ont marque cette evolution se sont 
produits a la fin des annees 90 avec l'arrivee de Java en 1995 et d'UML en 1997. 

Notre objectif est done de presenter l'essentiel des concepts objet qui nous 
paraissent necessaires a une bonne comprehension d'UML. Les concepts qui nous 
semblent importants a bien maitriser sont les suivants : 

• objet et classe, 

• encapsulation et interface, 

• association et agregation de classes, 

• generalisation et specialisation de classe, 

• polymorphisme, 

• persistance. 
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Nous n'utiliserons pas, par contre dans ce chapitre, de formalisme particulier de 
representation puisque nous ne voulons pas ajouter un formalisme de plus a celui 
deja defini dans UML. 

Nous precisons que nous nous limitons volontairement, dans le cadre de cet 
ouvrage, a une presentation generate des principaux concepts de I'approche objet. 
Le lecteur qui desire approfondir ses connaissances dans ce domaine pourra se re- 
porter aux nombreux ouvrages traitant en detail I'approche objet comme 
[Meyer2000]et [Bersini2004]. 

1.1.1 Objet et classe 

Concept d'objet 

Un objet represente une entite du monde reel (ou du monde virtuel pour les objets 
immateriels) qui se caracterise par un ensemble de proprietes (attributs), des etats 
significatifs et un comportement. 

L'etat d'un objet correspond aux valeurs de tous ses attributs a un instant donne. 
Les proprietes sont definies dans la classe d'appartenance de l'objet. Le comporte- 
ment d'un objet est caracterise par Pensemble des operations qu'il peut executer en 
reaction aux messages provenant des autres objets. Les operations sont definies dans 
la classe d'appartenance de l'objet. 

Exemple 

Considerons l'employe Durand, n° 1245, embauche en tant qu'ingenieur travaillant 
sur le site N. 

Cet objet est caracterise par la liste de ses attributs et son etat est represente par 
les valeurs de ses attributs : 

• n° employe : 1245, 

• nom : Durand, 

• qualification : ingenieur, 

• lieu de travail : site N. 

Son comportement est caracterise par les operations qu'il peut executer. Dans 
notre cas nous pouvons avoir les operations suivantes : 

• entrer dans l'organisme, 

• changer de qualification, 

• changer de lieu de travail, 

• sortir de l'organisme. 

Concept de classe 

Une classe est l'abstraction d'un ensemble d'objets qui possedent une structure iden- 
tique (liste des attributs) et un meme comportement (liste des operations). 
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Un objet est une instance d'une et une seule classe. Une classe abstraite est une 
classe qui n'a pas d'instance. Les concepts de classe et d'objet sont interdependants. 

Exemple 

Considerons la classe Employe qui represente Pensemble des employes d'une entre- 
prise. La description de la classe Employe comportera les elements suivants : 

• Nom de classe : Employe. 

• Attribute : 

- numero, 

- nom, 

- qualification, 

- site de travail. 

• Operations : 

- engager un employe, 

- consulter un employe, 

- modifier un employe, 

- depart d'un employe. 

1.1.2 Encapsulation et interface 

Par rapport a I'approche classique, I'approche objet se caracterise par le regroupe- 
ment dans une meme classe de la description de la structure des attribute et de la 
description des operations. Ce regroupement des deux descriptions porte le nom 
d'encapsulation donnees-traitements. 

Plus precisement, les donnees ne sont accessibles qu'a partir d'operations definies 
dans la classe. Le principe d'encapsulation renforce l'autonomie et Pindependance 
de chaque classe et donne une potentialite accrue de definition de classe reutilisable. 
Lensemble des operations d'une classe rendu visible aux autres classes porte le nom 
d'interface. Le schema d'ensemble du principe de l'encapsulation est presente a la 
figure 1.1. 

1.1.3 Association et agregation entre les classes 

L'association represente une relation entre plusieurs classes. Elle correspond a 
l'abstraction des liens qui existent entre les objets dans le monde reel. Les multipli- 
cites (ou cardinalites) et les roles des objets participant aux relations completent la 
description d'une association. Les exemples d'associations sont donnes directement 
dans les diagrammes de classe d'UML. 

Lagregation est une forme particuliere d'association entre plusieurs classes. Elle 
exprime le fait qu'une classe est composee d'une ou plusieurs autres classes. La rela- 
tion composant-compose ou la relation structurelle representant l'organigramme 
d'une entreprise sont des exemples types de la relation d'agregation. 



□ 
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CLASSE N 



Traitements 



Acces 



1- 



Operations accessibles 



Donnees : 
liste 

des attributs 



aux donnees 
via I'interface 
(partie visible 
de la classe) 



N 
T 
E 
R 
F 
A 
C 
E 



operation 1 
operation 2 
operation 3 



2- Operations non accessibles 

- operation A 

- operation B 




Figure 1.1 — Schema de principe de I'encapsulation 



1.1.4 Generalisation et specialisation de classe 

La generalisation de classes consiste a factoriser dans une classe, appelee super- 
classe, les attributs et/ou operations des classes considerees. Appliquee a l'ensemble 
des classes, elle permet de realiser une hierarchie des classes. 

La specialisation represente la demarche inverse de la generalisation puisqu'elle 
consiste a creer a partir d'une classe, plusieurs classes specialisees. 

Chaque nouvelle classe creee est dite specialisee puisqu'elle comporte en plus des 
attributs ou operations de la super-classe (disponibles par heritage) des attributs ou 
operations qui lui sont propres. 

Une classe specialisee porte aussi le nom de sous-classe. La specialisation de 
classe se construit en deux temps : d'abord par heritage des operations et des attributs 
d'une super-classe et ensuite par ajout d'operations et/ou d'attributs specifiques a la 
sous-classe. 

La generalisation-specialisation est un des mecanismes les plus importants de 
I'approche objet qui facilite la reutilisation des classes. 

1.1.5 Polymorphisme 

Le polymorphisme est la capacite donnee a une meme operation de s'executer diffe- 
remment suivant le contexte de la classe ou elle se trouve. 

Ainsi une operation definie dans une super-classe peut s'executer de maniere dif- 
ferente selon la sous-classe ou elle est heritee. 
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En fait lors de l'execution, l'appel de l'operation va automatiquement declencher 
l'execution de l'operation de la sous-classe concernee. Dans le deroulement de l'exe- 
cution de l'operation de la sous-classe, il est possible de faire appel a l'operation de la 
super-classe qui contient en general la partie commune applicable aux deux sous- 
classes. 

Exemple 

Soit la classe Employe et ses deux sous-classes Cadre et NonCadre. 

• Nom de classe : Employe. 

- Attributs : 

- numero, 

- nom, 

- salaire de base. 
-Operations : calculSalaire( ). 

• Nom de la sous-classe : Cadre. 

- Attributs : niveau d'encadrement. 
-Operations : calculSalaire( ). 

• Nom de la sous-classe : NonCadre. 

- Attributs : niveau de specialisation. 
-Operations : calculSalaire( ). 

Le principe de calcul du salaire etant de calculer pour chaque type d'employe une 
prime specifique en fonction soit du niveau d'encadrement, soit du niveau de specia- 
lisation selon le type d'employe. 

Voyons maintenant comment se realise Papplication du polymorphisme lors de 
l'execution des operations. 

Dans cet exemple, lorsque Ton appelle l'operation calculSalaire( ), c'est l'opera- 
tion de sous-classe Cadre ou celle de la sous-classe NonCadre qui est en fait activee 
selon l'objet concerne. L'operation de la sous-classe fait en general appel explicite- 
ment a l'operation calculSalaire( ) de la super-classe pour beneficier des traitements 
communs aux cadres et non cadres et ensuite il y aura poursuite du traitement speci- 
fique a la sous-classe. 

1.1.6 Persistence 

La persistance est la propriete donnee a un objet de continuer a exister apres la fin 
de l'execution du programme qui l'a cree. 

Par defaut dans I'approche objet, aucun objet n'est persistant. Les modeles decri- 
vent le systeme en execution en memoire centrale et ne tiennent pas compte a priori 
de l'etat du systeme qui doit etre stocke sur disque. 

La gestion de la memoire incombe au programmeur avec notamment le probleme 
de la liberation des espaces. 



□ 
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1.1.7 A vantages du developpement a I'aide des langages objet 

Par rapport a une approche fonctionnelle associee a un developpement classique 
mene a I'aide de langages proceduraux, on est en droit de s'interroger sur les avan- 
tages qu'apporte reellement le developpement a I'aide d'un langage objet comme par 
exemple C+ + , C# ou Java. 

En fait, deux avantages preponderants sont mis en general en avant lorsque Ton 
choisit une approche objet : 

• La modularite - Par construction, etant donne que Ton congoit des classes 
representant une entite de taille limitee en donnees et en operations, il est 
plus aise de construire des systemes modulables que si Ton elabore une seule 
base de donnees d'une part et un seul logiciel d'autre part. 

• La reutilisabilite - La definition d'un systeme a I'aide de classe ayant chacune 
la responsabilite d'un sous-ensemble de donnees et des operations associees 
favorise fortement la potentialite de trouver des classes reutilisables. La reuti- 
lisation de classe se realise soit sur le plan metier a Pinterieur d'une meme 
entreprise dans des applications differentes, soit sur le plan technique a 
l'echelle de tous les developpements realises a I'aide d'un meme langage. Sur 
ce dernier aspect, c'est toute I'approche du developpement par composant qui 
est en jeu. 

Au-dela de ces deux avantages majeurs et compte tenu de la plus grande modula- 
rite dans la construction d'une application a I'aide d'objets, la maintenance elemen- 
taire de chaque classe est en soi plus simple a realiser que celle d'un logiciel unique 
traitant toutes les donnees d'un systeme. II importe bien entendu dans I'approche 
objet de construire son systeme en veillant a minimiser le nombre de relations entre 
classes. 



1.2 PRESENTATION GENERALE D'UML 

1.2.1 Historique 

Regardons tout d'abord ce qui s'est passe au debut des annees 90. Par rapport a la 
cinquantaine de methodes d'analyse et de conception objet qui existaient au debut 
des annees 90, seulement trois d'entre elles se sont detachees nettement au bout de 
quelques annees. En effet, la volonte de converger vers une methode unifiee etait 
deja bien reelle et c'est pour cette raison que les methodes OMT, BOOCH et OOSE 
se sont demarquees des autres. 

OMT {Object Modeling Technique) de James Rumbaugh et BOOCH de 
Grady Booch ont ete les deux methodes les plus diffusees en France durant les 
annees 90. Par ailleurs, OOSE de Ivar Jacobson s'est aussi imposee dans le monde 
objet pour la partie formalisation des besoins. 
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Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se 
sont retrouves au sein de la societe Rational Software et ont ete ensuite rejoints par 
Ivarjacobson en se donnant comme objectif de fusionner leur methode et creer 
UML (Unified Methode Language). 

II est important de noter que contrairement a ce qui avait ete envisage au depart, 
le processus de developpement a ete sorti du champ couvert par le projet de norme. 

UML est done une norme du langage de modelisation objet qui a ete publiee, 
dans sa premiere version, en novembre 1997 par l'OMG (Object Management 
Group), instance de normalisation internationale du domaine de l'objet. 

En quelques annees, UML s'est imposee comme standard a utiliser en tant que 
langage de modelisation objet. 

Aujourd'hui, en cette fin de la premiere decennie des annees 2000, nous avons 
deja une dizaine d'annees de recul sur l'enseignement et la pratique d'UML en entre- 
prise. 



Les grandes etapes de la diffusion d'UML peuvent se resumer comme suit : 

1994-1996 : rapprochement des methodes OMT, BOOCH et OOSE et naissance de la 
premiere version d'UML. 

23 novembre 1997 : version 1.1 d'UML adoptee par l'OMG. 
1998-1999 : sortie des versions 1.2 a 1.3 d'UML. 
2000-2001 : sortie des dernieres versions suivantes 1.x. 
2002-2003 : preparation de la V2. 
10 octobre 2004 : sortie de la V2.1. 

5 fevrier 2007 : sortie de la V2.1.1 (version de reference du present ouvrage). 



1.2.2 Structuration de la presentation 

Nous proposons au lecteur une presentation detaillee d'UML 2 en privilegiant 
notamment dans les exemples et les etudes de cas le contexte d'utilisation des 
systemes d'information. Le lecteur pourra, s'il le souhaite ensuite, approfondir sa 
connaissance d'UML en consultant directement la norme de reference disponible 
via internet [OMG2007]. 

La presentation d'UML realisee dans le present ouvrage se veut synthetique et 
pragmatique. Nous n' avons pas voulu couvrir tous les details de la norme qui repre- 
sente aujourd'hui un volume de pres de 700 pages. 

Nous avons, tout d'abord, pris le parti d'illustrer systematiquement les concepts 
presented et la notation d'UML par des exemples concrets les plus proches possible 
du domaine de la gestion des entreprises. Ensuite nous donnons, pour les diagram- 
mes les plus structurants d'UML des exercices d'ensemble corriges et nous traitons 
aussi un exercice de synthese (Locagite) qui nous sert de fil conducteur et d'illustra- 
tion tout au long de l'ouvrage. 
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La presentation de la demarche que nous proposons UP7 s'appuie fortement sur 
le processus UP (Unified Process). 

Les deux etudes de cas traites dans cet ouvrage sont l'occasion de voir comment 
les principaux concepts et la notation d'UML peuvent s'appliquer sur des domaines 
d'etude plus importants que ceux des exercices et sont l'occasion de concretiser la 
demarche d'application d'UML que nous proposons. 

Nous sommes convaincus que cette presentation pragmatique d'UML, associee 
aux deux etudes de cas, doit constituer une aide efficace a tous ceux qui veulent soit 
s'initier a UML soit approfondir leur maitrise d'UML en particulier sur toutes les 
nouveautes apportees par UML 2. 

1.2.3 Regies generates 

Afin d'assurer un bon niveau de coherence et d'homogeneite sur l'ensemble des 
modeles, UML propose d'une part un certain nombre de regies d'ecriture ou de 
representations graphiques normalisees et d'autre part des mecanismes ou des 
concepts communs applicables a l'ensemble des diagrammes. Certains elements, 
comme les stereotypes, sont specifiquement prevus pour assurer une reelle capacite 
d'adaptation et devolution de la notation notamment pour prendre en compte les 
particularites des differentes situations a modeliser. Les principaux elements gene- 
raux d'UML que nous presentons sont : le stereotype, la valeur marquee, la note, la 
contrainte, et la relation de dependance. 

En outre UML propose un meta-modele de tous les concepts et notations asso- 
ciees utilises dans les treize diagrammes du langage de modelisation. 

Meta-modele 

Le langage de modelisation UML respecte un certain nombre de regies sur les 
concepts manipules (classes, attributs, operations, paquetages...) ainsi que sur la 
syntaxe d'ecriture et le formalisme de representation graphique. L'ensemble de ces 
regies constitue en soi un langage de modelisation qui a fait l'objet d'un meta- 
modele UML. L'interet de disposer d'un meta-modele UML permet de bien 
maitriser la structure d'UML et de faciliter son evolution. 

Cette approche a ete generalisee par l'OMG en normalisant la representation des 
meta-modeles par la definition en 1997 d'un meta meta-modele defini dans le MOF 
(Meta-Object Facility). Le MOF represente ainsi un super langage de definition des 
meta-modeles. 

Plus globalement, le MOF se retrouve au sommet d'une architecture de descrip- 
tion a quatre niveaux : 

• M3, niveau du MOF ; 

• M2, niveau des meta-modeles (UML est un des meta-modeles) ; 

• Ml, constitue par les modeles (les diagrammes d'UML sont des instances de 
ce niveau) ; 
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• MO, constitue par les instances (les realisations de diagrammes pour une situa- 
tion donnee sont des instances de ce niveau). 

Le meta-modele d'UML est completement decrit dans la norme. 

Stereotype 

Un stereotype constitue un moyen de classer les elements de la modelisation. Un 
certain nombre de stereotypes sont deja definis dans UML (voir annexe C de la 
norme), mais d'autres valeurs de stereotypes peuvent etre ajoutees si cela est neces- 
saire soit a revolution generale d'UML, soit a la prise en compte de situations parti- 
culieres propres aux entreprises. 

Les stereotypes peuvent s'appliquer a n'importe quel concept d'UML. Nous nous 
interesserons dans cet ouvrage a un certain nombre d'entre eux que nous presente- 
rons au niveau des diagrammes lorsque leur utilisation nous paraitra pertinente. 

En particulier, dans le diagramme de classe, le stereotype permet de considerer de 
nouveaux types de classe. Cette possibilite d'extension pour les classes, se definit 
done au niveau meta-classe. 

Formalisme et exemple 

Le nom du stereotype est indique entre guillemets. Un acteur peut etre vu comme un 
stereotype particulier d'une classe appelee acteur. L'exemple (fig. 1.2) montre une 
classe Client stereotypee comme « acteur ». 



Client 
« acteur » 



Figure 1.2 — Exemple d'une classe stereotypee 

Valeur marquee 

UML permet d'indiquer des valeurs particulieres au niveau des elements de modeli- 
sation et en particulier pour les attributs de classe. Une valeur marquee se definit au 
niveau meta-attribut. 

Formalisme et exemple 

La valeur marquee est mise entre accolades avec indication du nom et de la valeur : 
{persistance : string} si Ton veut aj outer ce type d'attribut dans une classe. 

Profil 

Afin de donner la possibilite de specialiser chaque application d'UML a son propre 
contexte, UML propose de definir un profil d'utilisation caracterise principalement 
par la liste des stereotypes, la liste des valeurs marquees et les contraintes specifiees 
pour un projet donne. 



10 



Chapitre 1. Concepts de I'approche objet et presentation d'UML 2 



Note 

Une note correspond a un commentaire explicatif d'un element d'UML. 
Formalisme et exemple 

La figure 1.3 montre le formalisme et un exemple de la representation d'une note. 



Commentaire 



Ce modele 
represente la vue 
des gestionnaires 



Figure 1.3 — Formalisme et exemple d'utilisation d'une note 



Contrainte 

Une contrainte est une note ayant une valeur semantique particuliere pour un 
element de la modelisation. Une contrainte s'ecrit entre accolades {}. Dans le cas ou 
la contrainte concerne deux classes ou plus, celle-ci s'inscrit a l'interieur d'une note. 

Formalisme et exemple 

• Premiere forme d'ecriture d'une contrainte : {ceci est une contrainte}. 

• Deuxieme forme d'ecriture : a l'interieur d'une note (fig. 1.4). 



Dans UML, un langage specifique d'expression de contraintes est disponible ; 
c'est le langage OCL (Object Contraint Language). Ce langage n'est pas decrit dans 
le present ouvrage. 



Parking 


posseder 


Resident 















{le parking 
d'un resident se trouve 
dans I'immeuble 
du resident} 



Immeuble 



resider 



Figure 1.4 — Exemple d'utilisation d'une contrainte 
(sans representation des multiplicites) 
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1.2.4 Presentation generale des diagrammes 

UML dans sa version 2 propose treize diagrammes qui peuvent etre utilises dans la 
description d'un systeme. Ces diagrammes sont regroupes dans deux grands ensem- 
bles. 

• Les diagrammes structurels - Ces diagrammes, au nombre de six, ont vocation 
a representer l'aspect statique d'un systeme (classes, objets, composants...). 

- Diagramme de classe - Ce diagramme represente la description statique du 
systeme en integrant dans chaque classe la partie dediee aux donnees et 
celle consacree aux traitements. C'est le diagramme pivot de l'ensemble de 
la modelisation d'un systeme. 

- Diagramme d'objet - Le diagramme d'objet permet la representation d'ins- 
tances des classes et des liens entre instances. 

- Diagramme de composant (modifie dans UML 2) - Ce diagramme represente 
les differents constituants du logiciel au niveau de l'implementation d'un 
systeme. 

- Diagramme de deploiement (modifie dans UML 2) - Ce diagramme decrit 
l'architecture technique d'un systeme avec une vue centree sur la repartition 
des composants dans la configuration d'exploitation. 

- Diagramme de paquetage (nouveau dans UML 2) - Ce diagramme donne une 
vue d'ensemble du systeme structure en paquetage. Chaque paquetage repre- 
sente un ensemble homogene d'elements du systeme (classes, compo- 
sants...). 

-Diagramme de structure composite (nouveau dans UML 2) - Ce diagramme 
permet de decrire la structure interne d'un ensemble complexe compose par 
exemple de classes ou d'objets et de composants techniques. Ce diagramme 
met aussi l'accent sur les liens entre les sous-ensembles qui collaborent. 

• Les diagrammes de comportement - Ces diagrammes representent la partie 
dynamique d'un systeme reagissant aux evenements et permettant de produire 
les resultats attendus par les utilisateurs. Sept diagrammes sont proposes par 
UML: 

- Diagramme des cas d 'utilisation - Ce diagramme est destine a representer les 
besoins des utilisateurs par rapport au systeme. II constitue un des diagram- 
mes les plus structurants dans l'analyse d'un systeme. 

- Diagramme d' etat-transition (machine d'etat) - Ce diagramme montre les dif- 
ferents etats des objets en reaction aux evenements. 

-Diagramme d'activites (modifie dans UML 2) - Ce diagramme donne une 
vision des enchainements des activites propres a une operation ou a un cas 
d'utilisation. II permet aussi de representer les flots de controle et les flots 
de donnees. 

-Diagramme de sequence (modifie dans UML 2) — Ce diagramme permet de 
decrire les scenarios de chaque cas d'utilisation en mettant l'accent sur la 
chronologie des operations en interaction avec les objets. 
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- Diagramme de communication (anciennement appele collaboration) - Ce dia- 
graming est une autre representation des scenarios des cas d'utilisation qui 
met plus l'accent sur les objets et les messages echanges. 

- Diagramme global d' interaction (nouveau dans UML 2) - Ce diagramme four- 
nit une vue generale des interactions decrites dans le diagramme de 
sequence et des flots de controle decrits dans le diagramme d'activites. 

-Diagramme de temps (nouveau dans UML 2) - Ce diagramme permet de 
representer les etats et les interactions d'objets dans un contexte ou le temps 
a une forte influence sur le comportement du systeme a gerer. 

Aujourd'hui UML 2 decrit les concepts et le formalisme de ces treize diagrammes 
mais ne propose pas de demarche de construction couvrant l'analyse et la concep- 
tion d'un systeme. Ce qui a pour consequence par exemple de ne pas disposer d'une 
vision des interactions entre les diagrammes. 

Formalisme et exemple 

Afin de donner un premier apergu des principaux diagrammes tant sur l'aspect du 
formalisme que sur leur usage, nous proposons a titre introductif un petit exemple 
tres simple. 

Considerons une nouvelle societe de formation qui souhaite developper un pre- 
mier niveau de site web dans lequel elle presente succinctement les formations pro- 
posees et enregistre en ligne les demandes de catalogue. 

Nous pouvons des ce stade de l'analyse representer le diagramme des cas d'utilisa- 
tion (fig. 1.5). 



Le diagramme de classe (fig. 1.6) va nous permettre de decrire les concepts mani 
pules, a savoir : Client, Catalogue et Formation. 




Client 



Figure 1.5 — Exemple de diagramme des cas d'utilisation 
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Client 






commander 


Catalogue 


numClient 
nomClient 


dateCatalogue 


+creer( ) 
+consulter( ) 




+creer( ) 
+consulter( ) 







Formation 






attributs 




codeFormation 
intituleFormation 






operations 




descriptionFormation 


rnntpnir 


--► 


+ajouterFormation( ) 
+consulterFormation( ) 







Figure 1.6 — Exemple de diagramme de classe 

Le diagramme de sequence va nous permettre de decrire les scenarios des cas 
d'utilisation du diagramme des cas d'utilisation. A titre d'exemple nous montrons 
(fig. 1.7) le scenario correspondant a la consultation du catalogue. 
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sd Consulter formation 



: Catalogue 



Formation 



Internaute 



consulterCatalogue( ) 



loop Consultation theme 
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consulterFormation( ) 



Echange de messages 
entre objets 



Figure 1.7 — Exemple de diagramme de classe 



Cette premiere illustration de trois diagrammes donne deja un eclairage sur les 
concepts importants que sont la classe, le cas d'utilisation et l'objet. 
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1.2.5 Schema d'ensemble des treize diagrammes d'UML 2 

Afin de donner quelques points de reperes sur le positionnement et les liens entre 
tous les diagrammes d'UML, nous donnons ici notre propre vision en proposant un 
regroupement des diagrammes en quatre ensembles suivant leur finalite : 

• description du systeme : huit diagrammes ; 

• architecture technique : deux diagrammes ; 

• vues globales ou specialisees : deux diagrammes ; 

• partition d'elements de la modelisation : un diagramme. 

Le schema propose reprend les treize diagrammes en les repartissant sur les quatre 
ensembles definis (fig. 1.8). 



Nous avons adopte, dans cet ouvrage, les abreviations suivantes pour les treize diagrammes : 


DAC 


Diagramme d'activite 


DCL 


Diagramme de classe 


DOB 


Diagramme d'objet 


DCP 


Diagramme de composant 


DCU 


Diagramme des cas d'utilisation 


DCO 


Diagramme de communication 


DET 


Diagramme d'etat-transition 


DGI 


Diagramme global d'interaction 


DPA 


Diagramme de paquetage 


DPL 


Diagramme de deploiement 


DSC 


Diagramme de structure composite 


DSE 


Diagramme de sequence 


DTP 


Diagramme de temps 
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Description du systeme 
nr.ii , t nsF n,, nr.n 

(interactions acteur/systeme) (interactions acteur/objets) 

DOB 

(objets) 

DCL 

DyAC (classes 7^ DE ' 
(processus, et associations) + (etats d'objet) 
flots de controle 
et de donnees) 

DTP 

(etats d'objet et temps) 


Vues 

globales 

ou 

specialisees 

DGI 

(vue macro 
de DAC et DSE) 

DSC 

(collaboration 

d'elements 

composites) 


Architecture technique 

DCP DPL 

(composants techniques) (deploiement 

des composants techniques) 


Description des elements de la modelisation 
DPA 

(structuration des elements de la modelisation en paquetage) 



Figure 1.8 — Schema d'ensemble des treize diagrammes d'UML 2 
Les noms en italiques representent les diagrammes de comportement 
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Les diagrammes structured 
(ou statiques) 



2.1 DIAGRAMME DE CLASSE (DCL) ET DIAGRAMME 
D'OBJET (DOB) 

Le diagramme de classe constitue l'un des pivots essentiels de la modelisation avec 
UML. En effet, ce diagramme permet de donner la representation statique du 
systeme a developper. Cette representation est centree sur les concepts de classe et 
d'association. Chaque classe se decrit par les donnees et les traitements dont elle est 
responsable pour elle-meme et vis-a-vis des autres classes. Les traitements sont mate- 
rialises par des operations. Le detail des traitements n'est pas represente directement 
dans le diagramme de classe ; seul l'algorithme general et le pseudo-code correspon- 
dant peuvent etre associes a la modelisation. 

La description du diagramme de classe est fondee sur : 

• le concept d'objet, 

• le concept de classe comprenant les attributs et les operations, 

• les differents types d'association entre classes. 

2.1.1 Objet 

Nous allons donner une premiere definition du concept d'objet avant de traiter le 
concept de classe. La description d'un objet sera completee simultanement a la 
presentation du concept de classe. 

Un objet est un concept, une abstraction ou une chose qui a un sens dans le con- 
texte du systeme a modeliser. Chaque objet a une identite et peut etre distingue des 
autres sans considerer a priori les valeurs de ses proprietes. 
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Exemple 

La figure 2.1 montre des exemples d'objets physiques (une chaise, une voiture, une 
personne, un velo) et d'objets de gestion (la Commande n° 12, le Client Durand). 




n°12 Durand 

Figure 2.1 — Exemples d'objets physiques et d'objets de gestion 
Autres caracteristiques 

Un objet est caracterise par les valeurs de ses proprietes qui lui conferent des etats 
significatifs suivant les instants consideres. Le formalisme de representation d'un 
objet est donne apres celui d'une classe. 

2.1.2 Classe, attribut et operation 

Classe 

Une classe decrit un groupe d'objets ayant les memes proprietes (attributs), un 
meme comportement (operations), et une semantique commune (domaine de defi- 
nition). 

Un objet est une instance d'une classe. La classe represente l'abstraction de ses 
objets. Au niveau de l'implementation, c'est-a-dire au cours de l'execution d'un pro- 
gramme, l'identificateur d'un objet correspond une adresse memoire. 

Formalisme general et exemple 

Une classe se represente a l'aide d'un rectangle comportant plusieurs compartiments. 
Les trois compartiments de base sont : 

• la designation de la classe, 

• la description des attributs, 

• la description des operations. 

Deux autres compartiments peuvent etre aussi indiques : 

• la description des responsabilites de la classe, 

• la description des exceptions traitees par la classe. 
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II est possible de manipuler les classes en limitant le niveau de description a un 
nombre reduit de compartiments selon les objectifs poursuivis par le modelisateur. 
Ainsi les situations suivantes sont possibles pour la manipulation d'une description 
restreinte de classe : 

• description uniquement du nom et des caracteristiques generates de la classe, 

• description du nom de la classe et de la liste d'attributs. 

La figure 2.2 montre le formalisme general des compartiments d'une classe et des 
premiers exemples. 



Nom de la classe 



Attributs 



Operations 



Responsabilites 
et/ou exception 



Voiture 



Marque 
Puissance 



Classe reduite 

a deux compartiments 




Description reduite 
a la designation 
de la classe 



Description complete 



Figure 2.2 — Formalisme general d'une classe et exemples 



Attribut 

Un attribut est une propriete elementaire d'une classe. Pour chaque objet d'une 
classe, l'attribut prend une valeur (sauf cas d'attributs multivalues). 

Formalisme et exemple 

La figure 2.3 montre le formalisme et un exemple de representation des attributs de 
classe. 



Nom de la classe 



Nom et caracteristique attribut 1 
Nom et caracteristique attribut 2 



Voiture 



Num immatriculation : texte 



Figure 2.3 — 



Formalisme d'attributs de classe et exemple 
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Caracteristiques 

Le nom de la classe peut etre qualifie par un « stereotype ». La description complete 
des attributs d'une classe comporte un certain nombre de caracteristiques qui 
doivent respecter le formalisme suivant : 

• Visibilite/Nom attribut : type [= valeur initiale {proprietes}] 

- Visibilite : se reporter aux explications donnees plus loin sur ce point. 

- Nom d' attribut : nom unique dans sa classe. 

-Type : type primitif (entier, chame de carac teres...) dependant des types 
disponibles dans le langage d'implementation ou type classe materialisant 
un lien avec une autre classe. 

- Valeur initiale : valeur facultative donnee a l'initialisation d'un objet de la 
classe. 

- {proprietes} : valeurs marquees facultatives (ex. : « interdit » pour mise a jour 
interdite). 

Un attribut peut avoir des valeurs multiples. Dans ce cas, cette caracteristique est 
indiquee apres le nom de l'attribut (ex. : prenom [3] pour une personne qui peut 
avoir trois prenoms). 

Un attribut dont la valeur peut etre calculee a partir d'autres attributs de la classe 
est un attribut derive qui se note « /nom de l'attribut derive ». Un exemple d'attribut 
derive est donne a la figure 2.5. 

Operation 

Une operation est une fonction applicable aux objets d'une classe. Une operation 
permet de decrire le comportement d'un objet. Une methode est l'implementation 
d'une operation. 

Formalisme et exemple 

Chaque operation est designee soit seulement par son nom soit par son nom, sa liste 
de parametres et son type de resultat. La signature d'une methode correspond au 
nom de la methode et la liste des parametres en entree. La figure 2.4 montre le 
formalisme et un exemple de representation d'operations de classe. 



Nom de la classe 



Nom et caracteristique attributs 



Nom et caracteristique operation 1 
Nom et caracteristique operation 2 



Voiture 



marque : texte 



rouler (vitesse) 



Figure 2.4 — 



Formalisme et exemple d'operations de classe 
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Caracteristiques 

La description complete des operations d'une classe comporte un certain nombre de 
caracteristiques qui doivent respecter le formalisme suivant : 

• Visibilite Nom d'operation (parametres) [:[type resultat] {proprietes}] 

- Visibilite : se reporter aux explications donnees plus loin sur ce point. 
-Nom d'operation : utiliser un verbe representant Taction a realiser. 

- Parametres : liste de parametres (chaque parametre peut etre decrit, en plus 
de son nom, par son type et sa valeur par defaut). L' absence de parametre 
est indiquee par ( ). 

- Type resultat : type de (s) valeur(s) retourne(s) dependant des types dispo- 
nibles dans le langage d'implementation. Par defaut, une operation ne 
retourne pas de valeur, ceci est indique par exemple par le mot reserve 
« void » dans le langage C++ ou Java. 

- {proprietes} : valeurs facultatives applicables (ex. : {query} pour un compor- 
tement sans influence sur l'etat du systeme). 

Exemples de classes et representation d'objets 

La figure 2.5 presente l'exemple d'une classe « Voiture ». La figure 2.6 donne le 
formalisme d'un objet. 



Voiture 



marque : texte 
puissance : entier 
cylindree : entier 
annee : entier 
/anciennete : entier 



demarrer ( ) 
rouler ( ) 
freiner ( ) 
arreter ( ) 



Figure 2.5 — Exemple de representation d'une classe 



Nom de I'objet (1) 



valeur attribut 1 
valeur attribut 2 
valeur attribut N 



Figure 2.6 — Formalisme de representation d'un objet 
(1 ) Le nom d'un objet peut etre designe sous trois formes : nom de I'objet, designation directe et 
explicite d'un objet ; nom de I'objet : nom de la classe, designation incluant le nom de la classe ; 
: nom de la classe, designation anonyme d'un objet d'une classe donnee. 
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II est utile de preciser que la representation des objets sera utilisee dans plusieurs 
autres diagrammes importants d'UML. C'est le cas notamment du diagramme de 
sequence ou encore du diagramme d'etat-transition. 

La figure 2.7 presente des exemples d'objets. 




Figure 2.7 — Exemples de representation d'objets 



Visibilite des attributs et operations 

Chaque attribut ou operation d'une classe peut etre de type public, protege, prive ou 
paquetage. Les symboles + (public), # (protege), - (prive) et ~ (paquetage) sont indi- 
ques devant chaque attribut ou operation pour signifier le type de visibilite autorise 
pour les autres classes. 

Les droits associes a chaque niveau de confidentialite sont : 

• Public (+) - Attribut ou operation visible par tous. 

• Protege (#) - Attribut ou operation visible seulement a Pinterieur de la classe 
et pour toutes les sous-classes de la classe. 

• Prive (-) - Attribut ou operation seulement visible a Pinterieur de la classe. 

• Paquetage (~) - Attribut ou operation ou classe seulement visible a Pinte- 
rieur du paquetage ou se trouve la classe. 

Exemple 

La figure 2.8 montre un exemple d'utilisation des symboles de la visibilite des 
elements d'une classe. 

Dans cet exemple, tous les attributs sont declares de type prive, les operations 
« demarrer » et « freiner » sont de type public, Poperation « rouler » est de type 
prive et Poperation « arreter » est de type protege. 

Attribut ou operation de niveau classe 
Caracteristiques 

Un attribut ou une operation peut etre defini non pas au niveau des instances d'une 
classe, mais au niveau de la classe. II s'agit soit d'un attribut qui est une constante 
pour toutes les instances d'une classe soit d'une operation d'une classe abstraite (voir 
§ 2.1.6) ou soit par exemple d'une operation « creer » qui peut etre definie au niveau 
de la classe et applicable a la classe elle-meme. 
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Voiture 



- marque 

- puissance 

- cylindree 
- annee 

- chiffreAffaire 



+ demarrer ( ) 
- rouler ( ) 
+ freiner ( ) 
# arreter ( ) 



Figure 2.8 — Exemple de representation des symboles de visibility 



Formalisme et exemple 

C'est le soulignement de l'attribut ou de l'operation qui caracterise cette propriete. 
Dans Pexemple de la figure 2.9, l'attribut « ristourne » est de type classe et l'opera- 
tion « creer » est une operation executable au niveau de la classe. 



Voiture 



- marque 

- puissance 

- cylindree 
- annee 

- chiffreAffaire 

- ristourne 



- creer ( ) 
+ demarrer ( ) 
+ rouler ( ) 
+ freiner ( ) 
+ arreter ( ) 



Figure 2.9 — Exemple d'attribut ou d'operation de niveau classe 



2.1.3 Association, multiplicite, navigabilite et contraintes 

Lien et association 

Un lien est une connexion physique ou conceptuelle entre instances de classes done 
entre objets. Une association decrit un groupe de liens ayant une meme structure et 
une meme semantique. Un lien est une instance d'une association. Chaque associa- 
tion peut etre identifiee par son nom. 

Une association entre classes represente les liens qui existent entre les instances 
de ces classes. 
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Formalisme et exemple 

La figure 2.10 donne le formalisme de Passociation. Le symbole (facultatif) indique 
le sens de lecture de l'association. Dans cette figure est donne aussi un exemple de 
representation d'une association. 



Nom de classe A 


Nom de l'association ► 


Nom de classe B 






Posseder ► 






Personne 


Voiture 









Figure 2.10 — Formalisme et exemple d'association 



Role d'association 

Le role tenu par une classe vis-a-vis d'une association peut etre precise sur l'associa- 
tion. 

Exemple 

La figure 2.11 donne un exemple de role d'association. 



Personne 


Travailler dans ► 


Entreprise 


nom 
prenom 


nom entreprise 
adresse 


employe employeur 







Figure 2.11 — Exemple de roles d'une association 



Multiplicite 

La multiplicite indique un domaine de valeurs pour preciser le nombre d'instance 
d'une classe vis-a-vis d'une autre classe pour une association donnee. La multiplicite 
peut aussi etre utilisee pour d'autres usages comme par exemple un attribut multi- 
value. Le domaine de valeurs est decrit selon plusieurs formes : 

• Intervalle ferme - Exemple : 2, 3 ..15. 

• Valeurs exactes - Exemple : 3, 5, 8. 
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• Valeur indeterminee notee * -Exemple : 1..*. 

- Dans le cas oil Ton utilise seulement *, cela traduit une multiplicite 0..*. 

- Dans le cas de multiplicite d'associations, il faut indiquer les valeurs mini- 
male et maximale d'instances d'une classe vis-a-vis d'une instance d'une 
autre classe. 

Formalisme et exemple 

Nous donnons, a la figure 2.12, quelques exemples des principales multiplicites defi- 
nies dans UML. 



A une instance de A correspond 
0 ou 1 instance de B. 
A une instance de B correspond 
0 a nombre non determine 
d'instances de A. 



A une instance de A correspond 

1 a un nombre non determine 
d'instances de B. 

A une instance de B correspond 

2 a 10 instances de A. 



A une instance de A correspond 
2 a 4 instances de B. 
A une instance de B correspond 
1 ou 3 instances de A. 



Figure 2.12 — Exemple de multiplicites 

Navigabilite 

La navigabilite indique si l'association fonctionne de maniere unidirectionnelle ou 
bidirectionnelle, elle est materialisee par une ou deux extremites flechees. La non- 
navigabilite se represente par un « X » 

Les situations possibles de navigabilite sont representees a la figure 2.13. 







0..1 




A 






B 







2..10 


1..* 


B 


A 





A 


1.3 2.A 


B 





• Navigabilite unidirectionnelle de A vers B. 

• Pas de navigabilite de B vers A 
(non definie explicitement). 



A 




B 


< 



• Navigabilite unidirectionnelle de B vers A. 

• Navigabilite de A vers B 
(non definie explicitement). 



A 




B 


< ► 



• Navigabilite bidirectionnelle entre A et B. 
Habituellement representee sans fleche. 



A 


X ► 


B 





Figure 2.13 — Representation de la navigabilite d'association 
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Par defaut, on admet qu'une navigabilite non definie correspond a une navigabi- 
lite implicite. 

Dans l'exemple donne a la figure 2.14, a une personne sont associees ses copies 
d'examen mais l'inverse n'est pas possible (retrouver directement l'auteur de la copie 
d'examen, notamment avant la correction de la copie). 



Personne 


1 produit 1..5 


Copie d'examen 


nom 
prenom 


numero copie 


K ► 







Figure 2.14 — Exemple de navigabilite d'une association 



Contraintes 

D'autres proprietes particulieres (contraintes) sont proposees dans UML pour 
preciser la semantique d'une association. 

Ordre de tri 

Pour une association de multiplicity superieure a 1 , les liens peuvent etre : 

• non ordonnes (valeur par defaut), 

• ordonnes ou tries lorsque Ton est au niveau de l'implementation (tri sur une 
valeur interne). 

Un exemple est donne a la figure 2.15. Dans cet exemple, pour une entreprise 
donnee, les personnes seront enregistrees suivant un ordre qui correspondra a un des 
attributs de Personne. 



Personne 


1..* Travailler dans 1,2 


Entreprise 


nom 
prenom 


nom entreprise 
adresse 


{ordonne} 







Figure 2.15 — Exemple de contrainte d'ordre d'une association 



Proprietes de mise a jour de liens 

II est possible d'indiquer des contraintes particulieres relatives aux conditions de 
mise a jour des liens. 

• {interdit} : interdit l'ajout, la suppression ou la mise a jour des liens. 

• {ajout seul} : n'autorise que l'ajout de liens. 
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Association de dimension superieure a 2 et classe-association 

Une association de dimension superieure a 2 se represente en utilisant un losange 
permettant de relier toutes les classes concernees. 

Une classe-association permet de decrire soit des attributs soit des operations 
propres a l'association. Cette classe-association est elle-meme reliee par un trait en 
pointille au losange de connexion. Une classe-association peut etre reliee a d'autres 
classes d'un diagramme de classes. 

Exemple 

Un exemple d'une association de dimension 3 comprenant une classe-association 
« Affectation » est donne a la figure 2.16. La classe-association Affectation permet 
de decrire les attributs propres a l'association de dimension 3 representee. 



Projet 
code projet 



affecter ( ) 



Personne 


* 


nom 
prenom 


Travailler 





Mobiliser 



-0- 



Employer 



Entreprise 



nom entreprise 
adresse 



Affectation 



date debut 
date fin 



Classe Association 



Figure 2.16 — Exemple d'une association de dimension 3 
et d'une classe-association 



2.1.4 Agregation et composition entre classes 

Agregation 

L'agregation est une association qui permet de representer un lien de type 
« ensemble » comprenant des « elements ». II s'agit d'une relation entre une classe 
representant le niveau « ensemble » et 1 an classes de niveau « elements ». L'agrega- 
tion represente un lien structurel entre une classe et une ou plusieurs autres classes. 
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Formalisme et exemple 

La figure 2.17 donne le formalisme general de Pagregation. 



Classe 1 



Classe 2 



Figure 2.17 — Formalisme de I'agregation 



La figure 2.18 montre un exemple de relation d'agregation. Dans cet exemple, nous 
avons modelise le fait qu'un ordinateur comprend une UC, un clavier et un ecran. 



Ordinateur 



puissance 
marque 





1 




1 




1 


u.c. 




Clavier 




Ecran 























Figure 2.18 — Exemple d'agregation 

Composition 

La composition est une relation d'agregation dans laquelle il existe une contrainte 
de duree de vie entre la classe « composant » et la ou les classes « compose ». Autre - 
ment dit la suppression de la classe « compose » implique la suppression de la ou des 
classes « composant ». 

Formalisme et exemple 

La figure 2.19 donne le formalisme general de la composition. La figure 2.20 montre 
un exemple de relation de composition. Une seconde forme de presentation peut 
etre aussi utilisee, elle est illustree a la figure 2.21. 
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Classe 1 



Classe « compose » 



Classe 2 



Classe « composant » 



Figure 2.19 — Formalisme de la composition 



Commande 



J 



1 








1..* 


En-tete 




Lignes commandes 











Figure 2.20 — Exemple d'une relation de composition 



Commande 



En-tete 1 



Lignes commandes 1. 



Figure 2.21 — Exemple de la seconde forme de representation 
de la relation de composition 
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2.1.5 Association qualifiee, dependance et classe d'interface 

Qualification 

La qualification d'une relation entre deux classes permet de preciser la semantique 
de l'association et de qualifier de maniere restrictive les liens entre les instances. 

Seules les instances possedant l'attribut indique dans la qualification sont con- 
cernees par l'association. Cet attribut ne fait pas partie de l'association. 

Formalisme et exemple 

Soit la relation entre les repertoires et les fichiers appartenant a ces repertoires. A un 
repertoire est associe 0 an fichiers. Si Ton veut restreindre cette association pour ne 
considerer qu'un fichier associe a son repertoire, la relation qualifiee est alors utilisee 
pour cela. La figure 2.22 montre la representation de ces deux situations. 



Repertoire 


1 contenir * 


Fichier 













Repertoire 



nom de fichier 



Fichier 



Figure 2.22 — Formalisme et exemple d'association qualifiee 

Dependance 

La dependance entre deux classes permet de representer l'existence d'un lien seman- 
tique. Une classe B est en dependance de la classe A si des elements de la classe A 
sont necessaires pour construire la classe B. 

Formalisme et exemple 

La relation de dependance se represente par une fleche en pointille (fig. 2.23) entre 
deux classes. 



Classe A 



Classe B 



Figure 2.23 — 



Formalisme de representation d'un lien de dependance 
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Interface 

Une classe d'interface permet de decrire la vue externe d'une classe. La classe 
d'interface, identified par un nom, comporte la liste des operations accessibles par les 
autres classes. Le compartiment des attributs ne fait pas partie de la description d'une 
interface. 

L'interface peut etre aussi materialisee plus globalement par un petit cercle asso- 
cie a la classe source. 

La classe utilisatrice de l'interface est reliee au symbole de l'interface par une fle- 
che en pointille. La classe d'interface est une specification et non une classe reelle. 
Une classe d'interface peut s'assimiler a une classe abstraite. 

Formalisme et exemple 

La figure 2.24 donne le formalisme, sur un exemple, des deux types de representation 
d'une interface. 



Fenetre 




Mot de passe 


code 


numero 


1 * 1 
Donneraccesa 

« utilise 


delacer ( ) 
ouvrir ( ) 
fermer ( ) 


controler ( ) 

' 7 ' 

✓ 

» 



■ v « realise » 



► Indique que la classe 
Fenetre realise 
l'interface Autorisation 



« interface » 
Autorisation 



ouvrir ( ) 



+'> Indique que la classe 
^ Mot de passe utilise 
l'interface Autorisation 



► Indique que la classe 

Mot de passe utilise 

une interface de la classe Fenetre 



Autorisation appelee Autorisation 



Fenetre 


— o 


Mot de passe 


code 




numero 


A * 1 

Donneraccesa 


delacer ( ) 
ouvrir ( ) 
fermer ( ) 


controler ( ) 



Figure 2.24 — 



Exemple de description d'une classe d'interface 
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2.1.6 Generalisation et specialisation 

La generalisation/specialisation et /'heritage simple 

La generalisation est la relation entre une classe et deux autres classes ou plus parta- 
geant un sous-ensemble commun d'attributs et/ou d'operations. 

La classe qui est affinee s'appelle super-classe, les classes affinees s'appellent 
sous-classes. L'operation qui consiste a creer une super-classe a partir de classes 
s'appelle la generalisation. Inversement la specialisation consiste a creer des sous- 
classes a partir d'une classe. 

Formalisme et exemple 

La figure 2.25 montre le formalisme de la generalisation-specialisation sous forme 
d'exemple general. Dans cet exemple : 

• la sous-classe Al herite de A, c'est une specialisation de A ; 

• la sous-classe A2 herite de A, c'est une specialisation de A. 



Classe A 



Specialisation 
(heritage) 



Generalisation 

A 



Sous-classe 
A1 



Sous-classe 
A2 



t 

Figure 2.25 — Formalisme de la relation de generalisation 



L'heritage permet a une sous-classe de disposer des attributs et operations de la 
classe dont elle depend. Un discriminant peut etre utilise pour exploiter le critere de 
specialisation entre une classe et ses sous-classes. Le discriminant est simplement 
indique sur le schema, puisque les valeurs prises par ce discriminant correspondent a 
chaque sous-classe. 
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La figure 2.26 montre un exemple de relation de specialisation. Dans cet exem- 
ple, les attributs nom, prenom et date de naissance et l'operation « calculer age » de 
« Employe » sont herites par les trois sous-classes : Employe horaire, Employe salarie, 
Vacataire. 

Classe abstraite 

Une classe abstraite est une classe qui n'a pas d'instance directe mais dont les classes 
descendantes ont des instances. Dans une relation d'heritage, la super-classe est par 
definition une classe abstraite. C'est le cas de la classe Employe dans l'exemple 
presente a la figure 2.26. 



Employe 

nom 
prenom 

date naissance 



calculer age ( ) 



Employe horaire 



taux horaire 
taux horaire 
supplemental 



calculer paie ( ) 



Employe salarie 



taux 

hebdomadaire 



calculer paie ( ) 



Vacataire 



taux journalier 



calculer paie ( ) 



Figure 2.26 — Exemple de relation de specialisation 



L'heritage avec recouvrement 

Par defaut, les sous-classes ont des instances disjointes les unes par rapport aux 
autres. Dans certains cas, il existe un recouvrement d'instances entre les sous-classes. 
D'une maniere generale, quatre situations peuvent se rencontrer et se representent 
sous forme de contraintes : 

• {chevauchement} : deux sous-classes peuvent avoir, parmi leurs instances, des 
instances identiques ; 

• {disjoint} : les instances d'une sous-classe ne peuvent etre incluses dans une 
autre sous-classe de la meme classe ; 
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• {complete} : la generalisation ne peut pas etre etendue ; 

• {incomplete} : la generalisation peut etre etendue. 

Dans certains cas, il est possible de ne pas citer toutes les sous-classes mais d'indi- 
quer seulementdes points de suspension (...). 

Formalisme et exemple 

La figure 2.27 montre un exemple d'heritage avec recouvrement d'instances entre 
les classes Etudiant et Employe. En effet, une meme personne peut etre a la fois 
etudiante dans une universite et employee dans une entreprise. 



Personne 



Etudiant 



{chevauchement} 



Employe 



Etre inscrit 



Travailler 



Universite 



Entreprise 



Figure 2.27 — Exemple d'heritage avec recouvrement d'instances 



Extension et restriction de classe 

L'ajout de proprietes dans une sous-classe correspond a une extension de classe. Le 
masquage de proprietes dans une sous-classe correspond a une restriction de classe. 

Formalisme et exemple 

La figure 2.28 montre un exemple d'heritage avec restriction et extension. 

L'heritage multiple 

Dans certains cas, il est necessaire de faire heriter une meme classe de deux classes 
« parentes » distinctes. Ce cas correspond a un heritage multiple. 

Exemple 

La figure 2.29 montre un exemple classique d'heritage multiple ou la classe « Vehicule 
amphibie » herite des classes « Vehicule terrestre » et « Vehicule marin ». 
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Classe A 



nom 

prenom 

age 



I 













Classe A1 


4 extension 

restriction 


Classe A2 


nom 
prenom 
age 
sexe 


nom 
age 


creer ( ) 


creer ( ) 







Figure 2.28 — Exemple d'heritage avec extension et restriction de proprietes 
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Exemple de relation d'heritage multiple 
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2.1.7 Stereotype de classe 

UML propose un certain nombre de stereotypes qui permettent de qualifier les 
profits d'utilisation. 

Parmi ces stereotypes, nous presentons ci-apres quatre d'entre eux : 

• « Classe d'implementation » - Ce stereotype est utilise pour decrire des clas- 
ses de niveau physique. 

• « Type » - Ce stereotype permet de specifier des operations applicables a un 
domaine d'objets. Exemple : Type Integer d'un langage de programmation. 

• « Utilitaire » - Ce stereotype qualifie toutes les fonctions utilitaires de base 
utilisees par les objets. 

• « MetaClasse » - Ce stereotype permet de regrouper des classes dans une 
famille de classe. 

2.1.8 Exercices 

Nous proposons au lecteur une serie de quatre exercices sur le diagramme de classe 
ainsi qu'un exercice de synthese (Locagite) pour lequel nous fournirons au fur et a 
mesure du parcours sur UML les principaux diagrammes. 

Exercice 1 

Enonce 

II est demande de representer le diagramme de classe d'une gestion technique de 
documents. Chaque document est compose d'un ou plusieurs feuillets. Un feuillet 
comporte du texte et des objets geometriques qui constituent deux types d'objets 
graphiques supportant des operations de type : selectionner, copier, couper, coller et 
deplacer. 

Nous considerons les quatre objets geometriques suivants : cercle, ellipse, carre, 
rectangle. II est demande d'utiliser les proprietes de la generalisation et la specialisa- 
tion afin de representer au mieux ces objets geometriques. 

Corrige 

La figure 2.30 propose au lecteur un corrige type. D'autres variantes peuvent etre 
envisagees notamment dans les choix de generalisation et specialisation. 

Exercice 2 

Enonce 

Une entreprise nationale de vente d'appareil electromenager souhaite realiser une 
premiere experience d'analyse objet avec la methode UML sur un petit sous- 
ensemble de son SI. Ce sous-ensemble concerne le suivi des personnels des agences 
locales implantees dans les regions. Chaque region est pilotee par une direction 
regionale qui a en charge un certain nombre d'agences locales. Une direction regio- 
nale est caracterisee par un code et un libelle. 
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Figure 2.30 — Diagramme de classe de I'exercice 



Chaque agence est caracterisee par un code, un intitule, une date de creation et 
une date de fermeture. 

A une agence sont rattachees une a plusieurs personnes. Chaque personne est 
caracterisee par les donnees : numero, qualite (M., Mme, Mile), nom, prenom, date 
de naissance, date previsionnelle d'arrivee, date d'arrivee et date de depart. 

II est demande d'elaborer le diagramme de classe de ce premier sous-ensemble du 
SI de cette entreprise. 

Corrige 

Les trois classes constituant ce systeme sont evidentes puisque deja bien identifiees 
dans Penonce : Direction regionale, Agence et Personnel. 

L'association entre Direction regionale et Agence est une agregation qui materia- 
lise une relation structurante entre ces classes. La relation entre Agence et Person- 
nel est une association de un a plusieurs. 

Les operations mentionnees dans chaque classe correspondent aux operations 
elementaires necessaires a la gestion du personnel des agences. 
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Le corrige type est donne a la figure 2.31. Nous donnons aussi, figure 2.32, un 
exemple de diagramme d'objet associe a ce diagramme de classe. 
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Figure 2.31 — Diagramme de classe de I'exercice 2 
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Figure 2.32 — Exemple de diagramme d'objet associe au diagramme de classe 

de I'exercice 2 
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Exercice 3 

Enonce 

La societe Forma possede un service qui gere la formation interne. Sa mission 
comporte plusieurs fonctions : 

• Elaborer les catalogues qui decrivent les cours et donnent les dates prevision- 
nelles des sessions. 

• Inscrire les personnes qui desirent participer aux sessions et leur envoyer leur 
convocation. 

• Determiner les formateurs qui vont animer les sessions et leur envoyer leur 
convocation (ces personnes sont choisies parmi celles qui peuvent enseigner 
un cours). Certaines sessions peuvent etre animees par une personne d'un 
organisme exterieur. 

• Faire le bilan des participations reelles aux formations. 

Les cours sont determines afin de repondre aux besoins de formation internes. 
Certains cours sont organises en filieres, c'est-a-dire qu'ils doivent etre suivis dans un 
certain ordre. Exemple : le cours ITE 16 (la demarche ITEOR OO) ne peut etre 
suivi avant ITE 03 (UML). Les cours utilisent des documents references (tab. 2.1). 



Tableau 2.1 — Documents references 



Liste des attributs 


Code cours 


N° catalogue 


Date catalogue 


N° document 


Date session 


N° session 


Duree cours 


Nom 


Etat de la session (prevue, annulee, en cours, close) 


Organisme exterieur 


Intitule du cours 


Prenom 


Lieu session 


Service 


Matricule 


Titre document 



Corrige 

La lecture du sujet et en particulier Panalyse des attributs indiques conduisent a 
identifier rapidement les classes suivantes : Session, Cours, Catalogue, Document, 
Personne et Organisme. 

Une reflexion complementaire menee sur la classe Personne permet de distinguer 
en fait trois sous-classes specialisees : PersonneExterne, PersonnelntNe (non ensei- 
gnante) et PersonnelntEn (enseignante). 

Le diagramme de classes peut etre elabore ensuite sans difficulte. La figure 2.33 
donne le corrige type de cet exercice. 
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Figure 2.33 — Diagramme de classe de I'exercice 3 



Exercice 4 

Enonce 

II vous est demande de gerer les apports de raisin de la cooperative viticole de cham- 
pagne. Le processus de traitements des apports de raisin correspond a un deroule- 
ment en plusieurs etapes. 

• Depart des camions pour le ramassage des raisins - Le ramassage est orga- 
nise par le responsable du transport. Tous les matins, durant la campagne de 
ramassage, chaque chauffeur- livreur charge dans son camion un certain 
nombre de palettes vides et passe a la pesee. Le responsable du transport 
enregistre le depart du camion en lui affectant un n° d'apport ainsi que son 
poids a vide (la gestion des itineraries ne fait pas partie de la presente 
etude). 

Les camions ont ete prealablement repertories par la cooperative avec leur 
capacite exprimee en nombre de palettes. II est frequent qu'un meme 
camion soit utilise pour plusieurs apports. 

• Retour des camions et pesee des apports - L'arrivee d'un camion de palettes 
de caisses de raisins correspond a un apport de raisin. Les date et heure d'arri- 
vee de cet apport sont soigneusement notees dans un registre avec le numero 
d'immatriculation du camion. 

Des l'arrivee d'un apport, les palettes sont dechargees puis pesees. Le poids et 
le nombre de caisses par palettes sont soigneusement controles par le respon- 
sable de la pesee puis enregistres. 
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• Constitution des lots - Apres la pesee des palettes regues, le responsable de la 
cooperative repartit l'apport en lots. Chaque lot correspond aux palettes 
contenant les raisins de meme cepage et de meme cm. Un exemple de lot est 
fourni ci-apres (tab. 2. 2) : il s'agit du troisieme lot de l'apport numero 3101 qui 
regroupe les palettes du Chardonnay en provenance de Cormigny. 

Le raisin de Champagne se divise en trois cepages : le Chardonnay qui est un raisin 
blanc, le Pinot noir et le Pinot meunier qui sont des raisins noirs. Le cru est la prove- 
nance du raisin : il correspond a un nom de commune et est identifie par le numero 
Insee de cette commune. Un cru possede un classement de 80 a 100 qui est remis en 
cause chaque annee. Les classements annuels successifs d'un cru doivent etre memorises. 

Les palettes appartiennent toutes a la cooperative. Elles possedent un numero qui 
est peint sur le bois et qui permet de les identifier sans ambiguite. Elles sont a la libre 
disposition des livreurs. Une meme palette peut servir plusieurs fois au cours d'une 
meme vendange. 

Un lot concerne un livreur. Tous les livreurs sont obligatoirement connus de la 
cooperative. Un bulletin d'information professionnel leur est adresse regulierement. 

Les livreurs sont des cooperateurs ou des particuliers independants. 

Les cooperateurs exploitent une ou plusieurs parcelles. Pour chaque livreur coo- 
perateur, le pourcentage de sa production qu'il apporte a la cooperative est enregis- 
tre. En aucun cas un cooperateur ne peut etre un independant et vice versa. 

En ce qui concerne les livreurs independants, il est important de connaitre le sta- 
tut juridique qu'ils ont choisi. Celui-ci est identifie par le code du statut et se carac- 
terise par un libelle (entreprise individuelle, societe a responsabilite limitee, societe 
cooperative d'exploitation agricole, etc.). 



Tableau 2.2 — Exemple de lot 



COOPERATIVE NOUVELLE DE CHAMPAGNE 
Apport n°: 3101 
Lot n°: 3 

Cepage : Chardonnay 

Cru : Cormigny 

Code Insee : 51231 

Nom du livreur : Dupond Laurent 


Numero 
de palette 


Nombre 
de caisses 


Poids net 
en kg 


428 


8 


459 


102 


14 


642 


14 


10 


670 


123 


12 


578 
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Corrige 

La lecture du sujet et en particulier Panalyse des attributs indiques conduisent a 
identifier rapidement les classes suivantes : Apport, Camion, Lot, Palette, Cepage, 
Commune, Livreur et Parcelle. 

Le diagramme de classes peut etre elabore ensuite sans difficulte. La figure 2.34 
donne le corrige type de cet exercice. 
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Figure 2.34 — 



Diagramme de classe de I'exercice 4 



2. 1 Diagramme de classe (DCL) et diagramme d'objet (DOB) 



43 



Exercice de synthese : Locagite 
Enonce 

« Locagite » est une association qui permet a divers proprietaires ruraux de mettre 
en location, a la semaine, des gites meubles. Elle publie annuellement un catalogue 
contenant les gites proposes par les proprietaires. Les gites doivent repondre a un 
certain nombre de criteres qualite, correspondant a un nombre d'etoiles, qui sont 
verifiees lors de P adhesion du gite et une fois tous les trois ans lors d'une visite de 
controle. Le proprietaire regoit tous les ans un catalogue des gites, et peut modifier 
les informations qui le concernent (prix par saison, photo du gite, nombre de 
personnes, de chambres, terrain...). 

« Locagite » regroupe 450 gites en France, pour une moyenne de 12 semaines de 
reservation par gite et par an. 

« Locagite » propose aux proprietaires qui le souhaitent, un service central de 
reservation. Tous les ans, les proprietaires qui veulent utiliser ce service signent un 
contrat avec « Locagite », qui specifie les periodes ouvertes a la location et la remu- 
neration de la centrale de reservation en pourcentage de chaque location, ce dernier 
taux etant valable pour Pannee et pour Pensemble des gites. Le proprietaire, en 
signant le contrat, joint un releve d'identite bancaire. 

Le proprietaire ayant signe le contrat de la reservation centrale regoit chaque 
mois un etat des reservations fermes. II regoit aussi tous les mois un etat des sommes 
encaissees par la centrale de reservation. Le virement bancaire des sommes dues, 
correspondant a Petat precedent, est envoye en milieu du mois suivant. 

Un client potentiel (que Ton peut appeler client reservataire) telephone a la cen- 
trale de reservation pour reserver un gite sur la base du catalogue. La centrale de 
reservation prend en compte la demande, et lui envoie un contrat de location ainsi 
qu'une demande d'acompte si un accord a ete trouve sur les dates de reservation. Le 
client reservataire renvoie le contrat signe accompagne de l'acompte : la reservation 
devient ferme. Un mois avant le sejour, le client locataire envoie le solde du 
paiement ; il regoit alors une confirmation de sejour lui donnant les coordonnees de 
la personne a contacter pour convenir de son arrivee. Le client peut a tout moment 
annuler son sejour, 30 % des sommes versees ne sont pas remboursees. En cas de 
non-retour du contrat signe apres 15 jours, la pre-reservation est automatiquement 
annulee. 

Corrige 

Elaboration du diagramme de classe : l'analyse de Pensemble des donnees disponi- 
bles nous permet de mettre en evidence les classes suivantes : Proprietaire, Gite, 
Gites geres, Catalogue, Activite, Periode Location, Reservation, Client et Contrat 
Location. Le diagramme de classe correspondant est donne a la figure 2.35. 
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Tableau 2.3 — Principales informations portees par les documents echanges 



Catalogue 


Annee du catalogue 
N° du gite 

Nom de la commune 
Adresse du gite 
Animaux acceptes (O, N) 
NB d'etoiles 

NB de personnes acceptees 


Capacite (nb. de chambres) 

Description du gite (texte) 

Adresse et tel. du proprietaire (pour la 

reservation) ou tel. du service de reservation 

Tarifs semaine (HS, juin/sept/Vac Scol) 

Activites disponibles et distance (ex. : piscine a 

3 km) 


Contrat proprietaire 


Etat mensuel des locations 


N° de contrat proprietaire 

N° proprietaire 

Nom du proprietaire 

Adresse et tel. du proprietaire 

Reference du gite 

Description du gite (voir ci-dessus) 

Tarifs semaine (HS, juin/sept/Vac Scol) 

Periodes de location 


N° proprietaire, nom du proprietaire, adresse et 
tel. du proprietaire 

Par contrat, par gite et par reservation : 
N° de reservation 
Date d'arrivee 
Date de depart 
NB de nuits 

Nom et adresse du locataire 
NB d'adultes 
NB d'enfants 
Animaux (O, N) 
Montant recu, 
Montant a recevoir 


Contrat de location 


N° du contrat 

Reference du gite 

Nom du proprietaire 

Ville ou village ou se situe le gite 

Dates d'arrivee et de depart 

Prix du sejour : 
Tarif de location = 

prix de la semaine * nombre de semaines 
Frais de dossiers (fixe) 
Assurance annulation (1,5 % de la 
location) 


Composition de la famille 

Nom 

Adresse 

NB adultes 

NB d'enfants 

Animaux domestiques (O, N) 
Telephone 


Prix total 




Conditions de reservation 


Acompte a recevoir : date et montant 
Solde a recevoir : date et montant 
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2.2 DIAGRAMME DE COMPOSANT (DCP) 

Le diagramme de composant permet de representer les composants logiciels d'un 
systeme ainsi que les liens existant entre ces composants. 

Les composants logiciels peuvent etre de deux origines : soit des composants 
metiers propres a une entreprise soit des composants disponibles sur le marche 
comme par exemple les composants EJB, CORBA, .NET, WSDL. 

2.2.1 Composant 

Chaque composant est assimile a un element executable du systeme. II est caracte- 
rise par : 

• un nom ; 

• une specification externe sous forme soit d'une ou plusieurs interfaces requi- 
ses 1 , soit d'une ou plusieurs interfaces fournies 2 ; 

• un port de connexion. 

Le port d'un composant represente le point de connexion entre le composant et 
une interface. Lidentification d'un port permet d'assurer une certaine independance 
entre le composant et son environnement exterieur. 

Formalisme general 

Un composant est represente (fig. 2.36) par un classeur avec le mot-cle « composant » 
ou bien par un classeur comportant une icone representant un module. 



«composant» „ 
Commande 



Figure 2.36 — Formalisme general d'un composant 



2.2.2 Les deux types de representation et exemples 

Deux types de representation sont disponibles pour modeliser les composants : une 
representation « boTte noire » et une representation « boite blanche ». Pour chaque 
representation, plusieurs modelisations des composants sont proposees. 



1. Une interface requise est une interface necessaire au bon fonctionnement du composant. 

2. Une interface fournie est une interface proposee par le composant aux autres composants. 



2.2 Diagramme de composant (DCP) 
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Representation « boite noire » 

C'est une vue externe du composant qui presente ses interfaces fournies et requises 
sans entrer dans le detail de Pimplementation du composant. Une boTte noire peut 
se representer de differentes manieres. 

Connecteur d'assemblage 

Une interface fournie se represente a l'aide d'un trait et d'un petit cercle et une 
interface requise a l'aide d'un trait et d'un demi-cercle. Ce sont les connecteurs 
d'assemblage. 

Un exemple de modelisation avec les connecteurs d'assemblage est donne a la 
figure 2.37, le composant Commande possede deux interfaces fournies et deux inter- 
faces requises. 



GestionCommande 

o 
o 

SuiviCommande 



«composant» 
Commande 



£1 



Personne 

r 



c 



Produit 



Figure 2.37 — Representation d'un connecteur d'assemblage 
Connecteur d'interfaces 

Une autre representation peut etre aussi utilisee en ayant recours aux dependances 
d'interfaces utilise et realise : 

• pour une interface fournie, c'est une relation de realisation partant du compo- 
sant et allant vers l'interface ; 

• pour une interface requise, c'est une dependance avec le mot-cle « utilise » 
partant du composant et allant vers l'interface. 

Un exemple de modelisation avec connecteurs d'interfaces est donne a la figure 2.38. 
Le composant Commande possede une interface fournie « GestionCommande » et une 
interface requise « Produit ». 



realisation 



L 



•interface » 
§ GeslionConiin.inile 



«cornpos»nt» 

Commande ^-1 
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interface » 

: PlOllllit 



Figure 2.38 — 



Representation d'un composant avec connecteur d'interfaces 
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Compart iment 

Une derniere maniere de modeliser un composant avec une representation boTte 
noire est de decrire sous forme textuelle les interfaces fournies et requises a l'inte- 
rieur d'un second compartiment. 

Un exemple de modelisation avec les compartiments est donne a la figure 2.39. 



« composant » 
Commande 



« interfaces fournies » 

GestionCommande 

SuiviCommande 

« interfaces requises » 

Produit 

Personne 



Figure 2.39 — Representation d'un composant avec compartiments 

Representation « boite blanche » 

C'est une vue interne du composant qui decrit son implementation a l'aide de clas- 
sificateurs (classes, autres composants) qui le composent. Plusieurs modelisations 
sont possibles pour la representation boite blanche. 

Compartiment 

Une maniere de modeliser un composant avec une representation boite blanche est 
de decrire sous forme textuelle les interfaces fournies et requises a Pinterieur d'un 
compartiment, les classificateurs (classes, autres composants) dans un autre compar- 
timent, les artefacts (element logiciel : jar, war, ear, dll) qui representent physique - 
ment le composant dans un dernier compartiment. 

Un exemple de modelisation avec les compartiments est donne a la figure 2.40. 



« composant » 
Commande 



« interfaces fournies » 

GestionCommande 
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« artifacts » 
Commande.jar 



Figure 2.40 — 



Representation boite blanche avec compartiments 
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Dependance 

Une autre representation interne du composant peut etre aussi utilisee en ayant 
recours aux dependances. Ainsi, les classificateurs qui composent le composant sont 
relies a celui-ci par une relation de dependance. 

Les relations entre les classificateurs (association, composition, agregation) sont 
aussi modelisees. Neanmoins, si elles sont trop complexes, elles peuvent etre repre- 
sentees sur un diagramme de classe relie au composant par une note. 

Un exemple de modelisation boite blanche avec les dependances est donne a la 
figure 2.41. 



«component» 
Commands 



L Det.illCoinmanile 



y LiijlieCommonde 



Figure 2.41 — Representation boite blanche avec dependances 
Ports et connecteurs 

Le port est represente par un petit carre sur le composant. Les connecteurs permettent 
de relier les ports aux classificateurs. lis sont representes par une association navigable 
et indiquent que toute information arrivee au port est transmise au classificateur. 

Un exemple de representation avec port et connecteur du composant Com- 
mande est donne a la figure 2.42. 
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Figure 2.42 — Representation boite blanche avec connecteurs 
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Dans Pexemple de la figure 2.42, le composant Commande est constitue de deux 
classes (classificateur) reliees par une agregation : DetailCommande et LigneCom- 
mande. 

L'interface fournie GestionCommande est accessible de Pexterieur via un port et 
permet d'acceder via les connecteurs aux operations des deux classes DetailCom- 
mande et LigneCommande (ajouterLigneCommande, calculTotal-Commande, 
calculPrixLigne ) . 

L'interface requise Personne est necessaire pour Paffichage du detail de la com- 
mande et est accessible via un port du composant Commande. 

L'interface requise Produit est necessaire pour le calcul du prix de la ligne de 
commande et est accessible via un port du composant Commande. 



2.3 DIAGRAMME DE DEPLOYMENT (DPL) 

Le diagramme de deploiement permet de representer l'architecture physique suppor- 
tant l'exploitation du systeme. Cette architecture comprend des nceuds correspondant 
aux supports physiques (serveurs, routeurs. . . ) ainsi que la repartition des artefacts logi- 
ciels (bibliotheques, executables. . . ) sur ces nceuds. C'est un veritable reseau constitue 
de nceuds et de connexions entre ces nceuds qui modelise cette architecture. 



2.3.1 Noeud 

Un noeud correspond a une ressource materielle de traitement sur laquelle des arte- 
facts seront mis en ceuvre pour l'exploitation du systeme. Les nceuds peuvent etre 
interconnectes pour former un reseau d'elements physiques. 

Formalisme et exemple 

Un nceud ou une instance de noeud se represente par un cube ou parallelepipede 
(fig. 2.43). 



noeud 



instanceNoeud 



serveur 
application 



serveur J2EE 



Figure 2.43 — 



Representation de nceuds 



2.3 Diagramme de deploiement (DPL) 
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Complements sur la description d'un noeud 

II est possible de representer des noeuds specialises. UML propose en standard les 
deux types de nceuds suivants : 

• Unite de traitement - Ce nceud est une unite physique disposant de capacite 
de traitement sur laquelle des artefacts peuvent etre deployes. 

Une unite de traitement est un nceud specialise caracterise par le mot-cle 
« device ». 

• Environnement d'execution - Ce nceud represente un environnement 
d'execution particulier sur lequel certains artefacts peuvent etre executes. 
Un environnement d'execution est un nceud specialise caracterise par le mot- 
cle « executionEnvironment ». 

2.3.2 Artefact 

Un artefact est la specification d'un element physique qui est utilise ou produit par 
le processus de developpement du logiciel ou par le deploiement du systeme. C'est 
done un element concret comme par exemple : un fichier, un executable ou une 
table d'une base de donnees. 

Un artefact peut etre relie a d'autres artefacts par notamment des liens de dependance. 

Formalisme et exemple 

Un artefact se represente par un rectangle (fig. 2.44) caracterise par le mot-cle 
« artifact » et/ou une icone particuliere dans le coin droit du rectangle. 



<<artifact>> p. 
commande.jar I I 



Figure 2.44 — Representation d'un artefact 

Deux complements de description sont proposes par UML pour la representation 
des artefacts. 

2.3.3 Specification de deploiement 

Une specification de deploiement peut etre associee a chaque artefact. Elle permet 
de preciser les conditions de deploiement de l'artefact sur le nceud sur lequel il va 
etre implante. 

Formalisme et exemple 

Une specification de deploiement se represente par un rectangle avec le mot-cle 
« deployment spec ». Un exemple d'un artefact avec une specification de deploie- 
ment est donne a la figure 2.45. 
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« deployement spec » 
SpecCommande 



Execution : execcmd 



Figure 2.45 — Exemple d'un artefact avec specification de deploiement 

2.3.4 Liens entre un artefact et les autres elements du diagramme 

II existe deux manieres de representer le lien entre un artefact et son nceud 
d'appartenance : 

• Representation inclusive - Dans cette representation, un artefact est repre- 
sente a l'interieur du nceud auquel il se situe physiquement. Un exemple est 
donne a la figure 2.46. 



CommandeServeurl 



«artifact» 
PriseCom.jar 



D 



«artifact» 
facture.jar 



D 



Figure 2.46 — Exemple de representation inclusive d'artefact 

Representation avec un lien de dependance type « deploy » - Dans ce cas 
l'artefact est represente a l'exterieur du nceud auquel il appartient avec un lien 
de dependance entre l'artefact et le nceud type avec le mot-cle « deploy ». Un 
exemple est donne a la figure 2.47. 



CommandeServeurl 



«deploy» / 



\ «deploy» 



«artifact» 
PriseCom.jar 



D 



«artifact» 
facture.jar 



Figure 2.47 — 



Exemple de representation d'artefact avec lien de dependance 
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Un artefact peut representer un ou plusieurs elements d'un modele. Le qualifica- 
tif « manifest » permet d'indiquer ce type de dependance. 



2.3.5 Representation et exemples 

Le diagramme de deploiement represente les nceuds de Parchitecture physique ainsi 
que Paffectation des artefacts sur les nceuds conformement aux regies de deploie- 
ment definies. Un premier exemple est donne a la figure 2.48. 



CommandeServeuii 



«artifact» rb. 
PriseCom.jar I I 



«artifact» R>| 
facture.jar I I 



"deployment spec" 
PriseComdescr.xml 



"deployment spec" 
facturedesc.xml 



Figure 2.48 — Exemple de representation d'un diagramme de deploiement 



Un second exemple relatif a une implementation d'une architecture J2EE avec 
quatre nceuds est donne a la figure 2.49. 

Dans l'exemple de la figure 2.49, plusieurs composants sont deployes. 

• Un serveur web ou se trouvent les elements statiques du site dans une 
archive : images, feuilles de style, pages html (static.zip). 

• Un serveur d'application « front » sur le lequel est deployee l'archive 
« front.ear » composee de l'application web « front. war » et d'autres compo- 
sants necessaires au fonctionnement de cette archive web comme « client- 
ejb.jar » (classes permettant l'appel aux EJB) et « commun.jar » (classes 
communes aux deux serveurs d'application). 

• Un serveur d'application metier sur lequel sont deployes les composants : 
« ejb.jar ». lis sont packages dans l'archive « metier. ear ». Deux autres archi- 
ves sont necessaires au fonctionnement des EJB : « dao.jar » (classes qui 
permettent l'acces a la base de donnees) et « commun.jar » (classes commu- 
nes aux deux serveurs d'application). 

• Un serveur BDD (base de donnees) sur lequel sont stockees des procedures 
stockees PL/SQL : « scripts. sql ». 
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<<device>> 
Serveur web 



<<artifact>> 
static.zip 



<<device>> 
Serveur application front 




<<artifact>> 
front.ear 




* — *X 


<<artifact>> 
front.war 


<<artifact>> <<artifact>> 
client-ejb.jar commun.jar 





<<device>> 
Serveur application metier 




<<artifact>> 
metier.ear 




.77 fs v.... 


<<artifact>> 
ejb.jar 


<<artifact>> <<artifact>> 
commun.jar dao.jar 





« device >> 
Serveur BDD 



<<artifact>> 
scripts.sql 



Figure 2.49 — Exemple de diagramme de deploiement comportant quatre nceuds 



2.4 DIAGRAMME DE PAQUETAGE (DPA) 

2.4.1 Paquetage 

Un paquetage regroupe des elements de la modelisation appeles aussi membres, 
portant sur un sous-ensemble du systeme. Le decoupage en paquetage doit traduire 
un decoupage logique du systeme a construire qui corresponde a des espaces de 
nommage homogenes. 



2.4 Diagramme de paquetage (DPA) 



55 



Les elements d'un paquetage peuvent avoir une visibilite declaree soit de type 
public ( + ) soit prive (-). 

Un paquetage peut importer des elements d'un autre paquetage. Un paquetage 
peut etre fusionne avec un autre paquetage. 

Formalisme et exemple 

La figure 2.50 montre le formalisme general d'un paquetage et les trois manieres de 
presenter un paquetage. 

• Representation globale - Le nom du paquetage se trouve a l'interieur du 
grand rectangle. 

• Representation detaillee - Les membres du paquetage sont representes et le 
nom du paquetage d'ensemble s'inscrit dans le petit rectangle. 

• Representation eclatee - Les membres du paquetage sont relies par un lien 
connecte au paquetage par le symbole ©. 



Nom du 
paquetage 



Membre A 




Membre B 



Figure 2.50 — Formalisme de representation de paquetages 



La figure 2.51 donne un exemple de representation eclatee. 



Gestion commerciale 



X 



Commande 



Facture 



Figure 2.51 — 



Exemple de representation eclatee d'un paquetage 
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2.4.2 Dependance entre paquetages 

La dependance entre paquetages peut etre qualifiee par un niveau de visibilite qui 
est soit public soit prive. Par defaut le type de visibilite est public. 

A chaque type de visibilite est associe un lien de dependance. Les deux types de 
dependances entre paquetages sont : 

• « import » - Ce type de dependance permet, pour un paquetage donne, 
d'importer l'espace de nommage d'un autre paquetage. Ainsi tous les membres 
du paquetage donne ont acces a tous les noms des membres du paquetage 
importe sans avoir a utiliser explicitement le nom du paquetage concerne. Ce 
type de dependance correspond a un lien ayant une visibilite « public ». 

• « access » - Ce type de dependance permet, pour un paquetage donne, 
d'avoir acces a l'espace de nommage d'un paquetage cible. L'espace de 
nommage n'est done pas importe et ne peut etre transmis a d'autres paqueta- 
ges par transitivite. Ce type de dependance correspond a un lien ayant une 
visibilite « prive ». 

Un exemple de dependance entre paquetages mettant en jeu les niveaux de visi- 
bilite est donne a la figure 2.52. 

Dans cet exemple, les elements de Clients externes sont importes dans Domaine 
client et ensuite dans Domaine tiers. Cependant, les elements de Clients internes 
sont seulement accessibles par le paquetage Domaine client et done pas a partir du 
paquetage Domaine tiers. 



Clients internes 



« access » 



Clients externes ic 



Domaine client 



« import » 



Domaine tiers 



« import » 



Figure 2.52 — Exemple de liens de dependance entre paquetages 



2.4.3 Representation et exemples 



En reprenant l'exemple type de l'exercice de synthese Locagite, nous donnons 
(fig. 2.53) une representation des liens de dependance entre paquetages. 
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« import » 




« access » 

« import » 
« import » 




Figure 2.53 — Exemple de liens de dependance entre paquetages de Locagite 



Enfin, UML propose aussi une operation de fusion entre deux paquetages. Le lien 
de dependance comporte dans ce cas le mot-cle « merge ». 

Ce type de lien permet de fusionner deux paquetages et d'obtenir ainsi un paque- 
tage contenant la fusion des deux paquetages d'origine. Pour bien clarifier cette ope- 
ration, il est important de qualifier par des roles les paquetages dans cette fusion. 
Ainsi trois roles sont a distinguer : 

• le paquetage a fusionner (entrant dans la fusion, mais preserve apres la fusion) ; 

• le paquetage recevant (paquetage d'origine avant la fusion, mais non conserve 
apres la fusion) ; 

• le paquetage resultat (paquetage contenant le resultat de la fusion et ecrasant 
le contenu du paquetage d'origine). 

Un exemple type de fusion entre deux paquetages est donne a la figure 2.54- 



Paquetage a fusionner 



Paquetage a fusionner 



Paquetage recevant 



A 



« merge » 



Paquetage d'origine 



^l ^usior^ ^ 

i 



/ « devenir » 



-* * 



Paquetage resultat 



Figure 2.54 — 



Exemple de liens de fusion entre paquetages 
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2.5 DIAGRAMME DE STRUCTURE COMPOSITE (DSC) 



Le diagramme de structure composite permet de decrire des collaborations 
d'instances (de classes, de composants . . . ) constituant des fonctions particulieres du 
systeme a developper. 



2.5.1 Collaboration 

Une collaboration represente un assemblage de roles d'elements qui interagissent en 
vue de realiser une fonction donnee. II existe deux manieres de representer une 
collaboration : 

• representation par une collaboration de roles, 

• representation par une structure composite : le diagramme de structure 
composite. 



2.5.2 Representation et exemples 

Representation par une collaboration de roles 

Dans ce cas, une collaboration est formalisee par une ellipse en pointille dans 
laquelle on fait figurer les roles des elements qui interagissent en vue de realiser la 
fonction souhaitee (fig. 2.55). Dans cet exemple, la fonction Persistance objets metier 
resulte d'une collaboration entre deux roles d'elements : 

• mapping : classeMetier, 

• stockage : tableBDD. 



Persistance objets metier 



mapping : classeMetier 




stockage : tableBDD 


\ 

1 




/ 

/ 


"s. 


*•* 











Figure 2.55 — Exemple de representation d'une structure composite 
a I'aide d'une collaboration de roles 



2.5 Diagramme de structure composite (DSC) 
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Representation par un diagramme de structure composite 

Cette nouvelle representation (fig. 2.56) permet de montrer plus explicitement les 
elements de la collaboration : 

• la collaboration representee par une ellipse en pointille ; 

• les elements participant a la collaboration (classe, composant...) representes 
a l'exterieur de la collaboration ; 

• les roles considered dans chaque participation representes sur les liens entre les 
elements participants et la collaboration. 



ClasseMetier 


' Persistance objets metier N 

/" -\ 

/ * 


TableBDD 






attributl 


1 1 

> / 


attributl 


attribut2 


\ / 


attribut2 




ma PP' n a n n stockage 





Figure 2.56 — Exemple de representation de collaboration d'instances 
par un diagramme de structure composite 

Dans cet exemple, la fonction Persistance objets metier resulte d'une collabora- 
tion entre la classe ClasseMetier consideree suivant le role mapping et la classe 
TableBDD consideree suivant le role stockage. 

Cette representation permet aussi de preciser les seuls attributs des classes parti- 
cipantes qui sont consideres suivant les roles pris en compte. 
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Les diagrammes 
comportementaux 



Les diagrammes comportementaux sont focalises sur la description de la partie dyna- 
mique du systeme a modeliser. Sept diagrammes sont proposes par UML 2 pour 
assurer cette description : 

• le diagramme des cas d'utilisation (DCU), 

• le diagramme d'etat- transition (machine d'etat, DET), 

• le diagramme d'activite (DAC), 

• le diagramme de sequence (DSE), 

• le diagramme de communication (DCO), 

• le diagramme global d'interaction (DGI), 

• le diagramme de temps (DTP). 



3.1 DIAGRAMME DES CAS D'UTILISATION (DCU) 

3.1.1 Presentation generale et concepts de base 

Les cas d'utilisation ont ete definis initialement par Ivar Jacobson en 1992 dans sa 
methode OOSE. Les cas d'utilisation constituent un moyen de recueillir et de 
decrire les besoins des acteurs du systeme. lis peuvent etre aussi utilises ensuite 
comme moyen d'organisation du developpement du logiciel, notamment pour la 
structuration et le deroulement des tests du logiciel. 
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Un cas d'utilisation permet de decrire Pinteraction entre les acteurs (utilisateurs 
du cas) et le systeme. La description de Pinteraction est realisee suivant le point de 
vue de Putilisateur. 

La representation d'un cas d'utilisation met en jeu trois concepts : Pacteur, le cas 
d'utilisation et Pinteraction entre Pacteur et le cas d'utilisation. 



Acteur 

Un acteur est un utilisateur type qui a toujours le meme comportement vis-a-vis 
d'un cas d'utilisation. Ainsi les utilisateurs d'un systeme appartiennent a une ou 
plusieurs classes d'acteurs selon les roles qu'ils tiennent par rapport au systeme. 

Une meme personne physique peut se comporter en autant d'acteurs differents 
que le nombre de roles qu'elle joue vis-a-vis du systeme. 

Ainsi par exemple, Padministrateur d'un systeme de messagerie peut etre aussi 
utilisateur de cette meme messagerie. II sera considere, en tant qu'acteur du systeme, 
dans le role d'administrateur d'une part et dans celui d'utilisateur d'autre part. 

Un acteur peut aussi etre un systeme externe avec lequel le cas d'utilisation va 
interagir. 

Formalisme et exemple 

Un acteur peut se representer symboliquement par un « bonhomme » et etre iden- 
tifie par son nom. II peut aussi etre formalise par une classe stereotypee « acteur » 
(fig. 3.1). 



o 



« acteur » 



Nom de I'acteur 



Figure 3.1 — Representations d'un acteur 



Cas d'utilisation et interaction 

Un cas d'utilisation correspond a un certain nombre d'actions que le systeme devra 
executer en reponse a un besoin d'un acteur. Un cas d'utilisation doit produire un 
resultat observable pour un ou plusieurs acteurs ou parties prenantes du systeme. 

Une interaction permet de decrire les echanges entre un acteur et un cas d'utili- 
sation. 



3. 1 Diagramme des cas d'utilisation (DCU) 



63 



Formalisme et exemple 

Un cas d'utilisation se represente par un ovale dans lequel figure son intitule. 

L'interaction entre un acteur et un cas d'utilisation se represente comme une 
association. Elle peut comporter des multiplicites comme toute association entre 
classes (voir § 2.1 Diagramme de classe). 

Le formalisme de base de representation d'un cas d'utilisation est donne a la 
figure 3.2. 




Norn de I'acteur 



Figure 3.2 — Formalisme de base de representation d'un cas d'utilisation 

Chaque cas d'utilisation doit etre decrit sous forme textuelle afin de bien identi- 
fier les traitements a realiser par le systeme en vue de la satisfaction du besoin 
exprime par I'acteur. 

3.1.2 Representation du diagramme des cas d'utilisation 

Tout systeme peut etre decrit par un certain nombre de cas d'utilisation correspon- 
dant aux besoins exprimes par Pensemble des utilisateurs. A chaque utilisateur, vu 
comme acteur, correspondra un certain nombre de cas d'utilisation du systeme. 
L'ensemble de ces cas d'utilisation se represente sous forme d'un diagramme. 

Exemple 

La figure 3.3 montre un exemple d'un systeme de messagerie comportant quatre cas 
d'utilisation. 

Nous verrons, dans la suite de la presentation d'UML, qu'un cas d'utilisation peut 
avoir une ou plusieurs instances representees par des scenarios. Chaque scenario 
fait l'objet lui-meme d'un diagramme de sequence ou de communication. 

En conclusion, nous dirons qu'un systeme est caracterise par son comportement 
vis-a-vis de ses utilisateurs. Ce comportement se represente sous forme d'un en- 
semble de cas d'utilisation qui correspond aux besoins des acteurs de ce systeme. 
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Systeme de messagerie 




Figure 3.3 — Exemple d'un systeme de messagerie 
comportant quatre cas d'utilisation 

3.1.3 Relations entre cas d'utilisation 

Afin d'optimiser la formalisation des besoins en ayant recours notamment a la reuti- 
lisation de cas d'utilisation, trois relations peuvent etre decrites entre cas 
d'utilisation: une relation d'inclusion (« include »), une relation d'extension 
( « extend » ) et une relation de generalisation. 

Relation d'inclusion 

Une relation d'inclusion d'un cas d'utilisation A par rapport a un cas d'utilisation B 
signifie qu'une instance de A contient le comportement decrit dans B. 

Formalisme et exemple 

La figure 3.4 donne le formalisme et un exemple d'une relation d'inclusion entre cas 
d'utilisation. 



3. 1 Diagramme des cas (/'utilisation (DCU) 
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Figure 3.4 — Formalisme et exemple de la relation d'inclusion 
entre cas d'utilisation 



Relation d'extension 

Une relation d'extension d'un cas d'utilisation A par un cas d'utilisation B signifie 
qu'une instance de A peut etre etendue par le comportement decrit dans B. Deux 
caracteristiques sont a noter : 

• le caractere optionnel de l'extension dans le deroulement du cas d'utilisation 
standard (A) ; 

• la mention explicite du point d'extension dans le cas d'utilisation standard. 
Formalisme et exemple 

La figure 3.5 donne un exemple d'une relation d'extension entre cas d'utilisation. 

Une note peut etre ajoutee a la representation du cas d'utilisation permettant 
d'expliciter la condition. 

Relation de generalisation 

Une relation de generalisation de cas d'utilisation peut etre definie conformement 
au principe de la specialisation-generalisation deja presentee pour les classes. 

Formalisme et exemple 

La figure 3.6 donne un exemple d'une relation de generalisation de cas d'utilisation. 
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Figure 3.5 — Formalisme et exemple d'une relation d'extension 
entre cas d'utilisation 




Figure 3.6 — Exemple d'une relation de generalisation de cas d'utilisation 



3.1.4 Description textuelle d'un cas d'utilisation 

A chaque cas d'utilisation doit etre associee une description textuelle des interac- 
tions entre l'acteur et le systeme et les actions que le systeme doit realiser en vue de 
produire les resultats attendus par les acteurs. 

UML ne propose pas de presentation type de cette description textuelle. Cepen- 
dant, les travaux menes par Alistair Cockburn [Cockburn2001] sur ce sujet consti- 
tuent une reference en la matiere et tout naturellement nous reprenons ici l'essentiel 
de cette presentation. 



3. 1 Diagramme des cas (/'utilisation (DCU) 
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La description textuelle d'un cas d'utilisation est articulee en six points : 

• Objectif - Decrire succinctement le contexte et les resultats attendus du cas 
d'utilisation. 

• Acteurs concernes - Le ou les acteurs concerned par le cas doivent etre iden- 
tifies en precisant globalement leur role. 

• Pre conditions - Si certaines conditions particulieres sont requises avant 
l'execution du cas, elles sont a exprimer a ce niveau. 

• Post conditions - Par symetrie, si certaines conditions particulieres doivent 
etre reunies apres l'execution du cas, elles sont a exprimer a ce niveau. Pour 
notre part, par souci de simplification nous n'avons pas traite ce point dans les 
exercices et etudes de cas presentes. 

• Scenario nominal - II s'agit la du scenario principal qui doit se derouler sans 
incident et qui permet d'aboutir au resultat souhaite. 

• Scenarios alternatifs - Les autres scenarios, secondaires ou correspondant a la 
resolution d' anomalies, sont a decrire a ce niveau. Le lien avec le scenario 
principal se fait a l'aide d'une numerotation hierarchisee (1.1a, 1.1b...) rappe- 
lant le numero de Taction concernee. 

3.1.5 Exercices 

Exercice 1 

Enonce 

Une bibliotheque universitaire souhaite automatiser sa gestion. Cette bibliotheque 
est geree par un gestionnaire charge des inscriptions et des relances des lecteurs 
quand ceux-ci n'ont pas rendu leurs ouvrages au-dela du delai autorise. Les biblio- 
thecaires sont charges de gerer les emprunts et la restitution des ouvrages ainsi que 
l'acquisition de nouveaux ouvrages. 

II existe trois categories d'abonne. Tout d'abord les etudiants qui doivent seule- 
ment s'acquitter d'une somme forfaitaire pour une annee afin d' avoir droit a tous les 
services de la bibliotheque. L'acces a la bibliotheque est libre pour tous les ensei- 
gnants. Enfin, il est possible d'autoriser des etudiants d'une autre universite a s'ins- 
crire exceptionnellement comme abonne moyennant le versement d'une cotisation. 
Le nombre d'abonne externe est limite chaque annee a environ 10 % des inscrits. 

Un nouveau service de consultation du catalogue general des ouvrages doit etre 
mis en place. 

Les ouvrages, souvent acquis en plusieurs exemplaires, sont ranges dans des 
rayons de la bibliotheque. Chaque exemplaire est repere par une reference geree 
dans le catalogue et le code du rayon ou il est range. 

Chaque abonne ne peut emprunter plus de trois ouvrages. Le delai d'emprunt 
d'un ouvrage est de trois semaines, il peut cependant etre prolonge exceptionnelle- 
ment a cinq semaines. 

II est demande d'elaborer le diagramme des cas d'utilisation (DCU). 
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Corrige 

Representation du DCU - La figure 3.7 propose un corrige-type de cet exercice. Six 
cas d'utilisation peuvent etre identifies : 

inscription a la bibliotheque, 
consultation du catalogue, 
emprunt d'ouvrages, 
restitution d'ouvrages, 
approvisionnement d'ouvrages, 
relance emprunteur. 

Comme le montre la figure 3.7, cinq types d'acteurs peuvent etre identifies : 
etudiant, 
externe, 
emprunteur, 
gestionnaire, 
bibliothecaire. 




Figure 3.7 — Corrige type de I'exercice 1 sur les cas d'utilisation 



3. 1 Diagramme des cas d'utilisation (DCU) 
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Exercice de synthese 

En reprenant l'enonce de l'exercice de synthese Locagite, nous allons elaborer le 
diagramme des cas d'utilisation des quatre activites decrites : 

• Catalogue, cette activite se decompose en trois cas d'utilisation : 

- cas d'utilisation 1.1 : Gestion annuelle du catalogue 

- cas d'utilisation 1.2 : Publication du catalogue 

- cas d'utilisation 1 .3 : Controle annuel de l'etat du gite 

• Proprietaire, cette activite se decompose en deux cas d'utilisation : 
-cas d'utilisation 2.1 : Gestion proprietaire 

- cas d'utilisation 2.2 : Authentification proprietaire 

• Reservation, cette activite decompose en deux cas d'utilisation : 

- cas d'utilisation 3.1 : Gestion des reservations 

- cas d'utilisation 3.2 : Authentification client 

• Location, cette activite se decompose en deux cas d'utilisation : 

- cas d'utilisation 4-1 : Gestion des locations 

- cas d'utilisation 4-2 : Gestion des annulations 

Pour ces cas d'utilisation consideres, quatre acteurs types externes peuvent etre 
identifies : 

• le proprietaire, 

• le proprietaire adherent (qui met en location son gite), 

• le client reservataire, 

• le client locataire. 

Deux acteurs internes peuvent etre identifies : 

• le gestionnaire Catalogue-Proprietaire, 

• le gestionnaire Reservation-Location. 

Le diagramme de ces cas d'utilisation est donne a la figure 3.8. 



Dans le cadre de cet exercice de synthese, nous nous limiterons a donner la description 
textuelle des scenarios des cas d'utilisation de I'activite catalogue (cas 1.1, 1.2 et 1.3). 

Cas d'utilisation 1.1 : Gestion annuelle du catalogue 

Deux scenarios peuvent etre consideres : la creation du gite et la modification du gite. 
Scenario 1.1.1 « Creation gite » 

• Objectif- Permettre l'ajout d'un gite dans le catalogue. 

• Acteurs concernes - Gestionnaire catalogue. 

• Pre conditions - Aucune. 
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Scenario nominal 

- 1. Creer un nouveau proprietaire s'il n'existe pas. 

- 2. Creer un gite. 

- 3. Aj outer le gite cree au catalogue. 
Scenarios alternatifs 

- 1-a : Erreurs detectees dans la saisie du proprietaire : 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detectees. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend a Taction 1 du scenario nominal. 

- 2-a : Erreurs detectees dans la saisie du gite : 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detectees. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend a Taction 2 du scenario nominal. 



1.1 Gestion annuelle du catalogue^) 
~~ 3 ■ ft; 



Proprietaire 



Gestionnaire catalogue 



«extend» 



: «extend>*.. 
:«include> 



^TJ^Publication catalogue^ ^I^Mise ajourannuellegTte^^ 



^^2Authentification proprietaire"^^ 

«include» 



2.1 Gestion proprietaire 



Proprietaire adherent 





^3^Gestion reservation^ 

Client reservataire Gestionnaire reservation 

A / "\ 

„."'«include» «extend>>°'-... 



(^2Authentification cHejrt^ <^2Gestion annuNrttoJT} 



«extend» 

«include» 4i_ 



"i^Xl^^estion location^ 



Client locataire 

Figure 3.8 — Diagramme des cas d'utilisation de Locagite 



3. 1 Diagramme des cas d'utilisation (DCU) 



Scenario 1.1.2 « Modification gite » 

• Objectif- Permettre la modification d'un gite deja present dans le catalogue. 

• Acteurs concernes - Gestionnaire catalogue. 

• Pre conditions - Aucune. 

• Scenario nominal 

- 1. Saisie et controle d'existence du gite. 

- 2. Saisie et controle d'existence du proprietaire. 

- 3. Modification des donnees du gite. 

- 4- Modification eventuelle des activites du gite, 

• Scenarios alternatifs 

- 1-a : Erreur de saisie du gite : 

- Le systeme reaffiche le formulaire de saisie en indiquant l'erreur detectee. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend a Taction 1 du scenario nominal. 

- 2-a : Erreurs de saisie du proprietaire : 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detectees. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend a Taction 2 du scenario nominal. 

Cas d'utilisation 1.2 : Publication du catalogue 

Ce cas d'utilisation ne comporte qu'un seul scenario. 

Scenario « Publication du catalogue » 

• Objectif - Permettre Tedition du catalogue. 

• Acteurs concernes - Gestionnaire catalogue. 

• Pre conditions - Aucune. 

• Scenario nominal - Pour chaque gite : 

- 1. Rechercher les informations sur le proprietaire. 

- 2. Afficher les tarifs de location a la semaine. 

- 3. Afficher les activites disponibles. 

• Scenarios alternatifs - Aucun. 

Cas d'utilisation 1.3 : Mise a jour annuelle du gite 

Ce cas d'utilisation ne comporte qu'un seul scenario. 

Scenario « Mise a jour annuelle du gite » 

• Objectif - Permettre la mise a jour du nombre d'etoile d'un gite donne. 

• Acteurs concernes - Gestionnaire catalogue. 

• Pre conditions - Aucune. 

• Scenario nominal : 

- 1. Saisir le code proprietaire, le code du gite et le nombre d'etoile. 

- 2. Mettre a jour le nombre d'etoile. 
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• Scenarios alternatifs : 

- 1-a : le proprietaire ou le gite n'existe pas : 

- Le systeme reaffiche le formulaire de saisie en indiquant l'erreur detectee. 

- Le gestionnaire corrige les erreurs. 

- Le cas d'utilisation reprend a Taction 1 du scenario nominal. 



3.2 DIAGRAMME D'ETAT-TRANSITION (DET) 



3.2.1 Presentation generate et concepts de base 

Etat-transition et evenement 

L'etat d'un objet est defini, a un instant donne, par l'ensemble des valeurs de ses 
proprietes. Seuls certains etats caracteristiques du domaine etudie sont consideres. 

Le passage d'un etat a un autre etat s'appelle transition. Un evenement est un 
fait survenu qui declenche une transition. 

II existe quatre types d'evenements : 

• Type appel de methode (call) - C'est le type le plus courant que nous traite- 
rons dans la suite de la presentation. 

• Type signal - Exemple : clic de souris, interruption d'entrees-sorties... La 
modelisation de la reception ou Pemission d'un signal est traitee dans le 
diagramme d'activite. 

• Type changement de valeur (vrai/faux) - C'est le cas de revaluation d'une 
expression booleenne. 

• Type ecoulement du temps - C'est un evenement lie a une condition de type 
after (duree) ou when (date). 

Formalisme et exemple 

Un objet reste dans un etat pendant une certaine duree. La duree d'un etat corres- 
pond au temps qui s'ecoule entre le debut d'un etat declenche par une transition i et 
la fin de l'etat declenche par la transition i+l. Une condition, appelee « garde », 
peut etre associee a une transition. 

Le formalisme de representation d'etat-transition est donne a la figure 3.9. 




Evenement [condition] 




Figure 3.9 — 



Formalisme d'etat-transition 
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La figure 3.10 donne un premier exemple d'etat-transition. Dans cet exemple, 
pour un employe donne d'une entreprise, nous pouvons considerer les deux etats 
significatifs suivants : etat recrute, etat en activite. 



Candidature 
acceptee 



Employe 
recrute 



Prise de fonction [date d'embauche echue] 



Employe 
en activite 



Figure 3.10 — Exemple d'etat-transition 



Action et activite 

Une action est une operation instantanee qui ne peut etre interrompue ; elle est 
associee a une transition. 

Une activite est une operation d'une certaine duree qui peut etre interrompue, 
elle est associee a un etat d'un objet. 

Formalisme et exemple 

Le formalisme de representation d'etat-transition comprenant la representation 
d'action et/ou activite est donne a la figure 3.11. 



Etat 1 
Faire activite 1 



Evenement [condition]/action 



Etat 2 
Faire activite 2 



Figure 3.11 — Formalisme d'etat-transition avec action et activite 



La figure 3.12 montre un exemple des actions et activites d'etats ainsi que la des- 
cription complete d'une transition. 



Etat 1 
faire : travaille 



Maladie [avec arret]/mise en arret 



Etat 2 
faire : mise en arret 



Figure 3.12 — Exemple d'etat-transition avec action et activite 



3.2.2 Representation du diagramme d'etat-transition d'un objet 

L'enchainement de tous les etats caracteristiques d'un objet constitue le diagramme 
d'etat. Un diagramme d'etats debute toujours par un etat initial et se termine par un 
ou plusieurs etats finaux sauf dans le cas ou le diagramme d'etats represente une 
boucle. A un evenement peut etre associe un message compose d'attributs. 
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Formalisme et exemple 

Le formalisme de representation des etats initial et final est donne a la figure 3.13. 



Evenement 1 [condition 1]/action 1 
/ 



Evenement 2 [condition 2]/action 2.. 



Etat 1 
initial 



Etat 2 



> 








f \ 






Etat 3 




Etat 4 




► 




final 


i 




>■ 







-® 



Figure 3.13 — Formalisme de representation des etats initial et final 



Afin de nous rapprocher des situations reelles, nous proposons a la figure 3.14 un 
premier exemple tire d'une gestion commerciale qui montre le diagramme d'etat- 
transition de l'objet client. 



Client 
prospect 




Ne passe plus 
commande 



Client 
en contentieux 




Client 
supprime 



Une annee 
sans commande 



I 



Fin du 
contentieux 



Figure 3.14 — Diagramme d'etat-transition de l'objet client d'une gestion commerciale 



Nous proposons comme second exemple, a la figure 3.15, le diagramme d'etat- 
transition de l'objet « personnel » qui se caracterise par trois etats : 

• En prevision d'arrivee : si la date previsionnelle est posterieure a la date du 
jour. 

• En activite : etat qui correspond a un personnel ayant une date d'arrivee 
renseignee. 

• Parti : etat qui correspond a un personnel ayant une date de depart rensei- 
gnee. 



3.2 Diagmmme d'etat-transition (DET) 
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Ordre de recrutement d'un personnel [date-previsionnelle > date du jour]/creer ( ) 



En prevision 
d'arrivee 



Prise de fonction 



En activite 



Action : renseigner la date 
d'arrivee a I'aaence 



Depart de I'agence 



IK" 



Parti 



Action : renseigner la date 
de depart de la personne 



Figure 3.15 — Exemple de diagramme d'etat-transition 



3.2.3 Complements sur le diagramme d'etat-transition 

Composition et decomposition d'etat 

II est possible de decrire un diagramme d'etat-transition a plusieurs niveaux. Ainsi, a 
un premier niveau, le diagramme comprendra des etats elementaires et des etats 
composites. Les etats composites seront ensuite decrits a un niveau elementaire 
dans un autre diagramme. On peut aussi parler d'etat compose et d'etat composant. 

Formalisme et exemple 

Le formalisme de representation d'etats composites est donne a la figure 3.16. 



Recu 



^enregistre/controler 



Controle 



controle/decider/' 



Accepte 



Symbole de representation 
d'un etat composite 



Detail de I'etat 
composite 



controle n D SS 



controler feuille 



controle des droits 



;H§> 



Figure 3.16 — 



Exemple d'etat composite 



76 



Chapitre 3. Les diagrammes comportementaux 



Dans cet exemple, l'etat controle est un etat composite qui fait l'objet d'une des- 
cription individualisee a un second niveau que Ton appelle aussi sous-machine d'etat. 

Point d'entree et de sortie 

Sur une sous-machine d'etat, il est possible de reperer un point d'entree et un point 
de sortie particuliers. 

Formalisme et exemple 

Le formalisme de representation d'une sous-machine d'etat avec point d'entree et de 
sortie est donne a la figure 3.17. 



Etat amont 



Entree 
standard 



Sous-machine d'etat 




Q Point d'entree (particulier ou standard) Point de sortie (particulier) 

Figure 3.17 — Exemple d'une sous-machine d'etat avec point d'entree et de sortie 



Point de jonction 



Lorsque Ton veut relier plusieurs etats vers d'autres etats, un point de jonction 
permet de decomposer une transition en deux parties en indiquant si necessaire les 
gardes propres a chaque segment de la transition. 

A l'execution, un seul parcours sera emprunte, c'est celui pour lequel toutes les 
conditions de garde seront satisfaites. 

Formalisme et exemple 

Le formalisme de representation d'etats-transitions avec point de jonction est donne 
a la figure 3.18. 



Point de choix 



Le point de choix se comporte comme un test de type : si condition faire actionl 
sinon faire action2. 

Formalisme et exemple 

Le formalisme de representation d'etats composites est donne a la figure 3.19. 



3.2 Diagramme d'etat-transition (DET) 
0 Point dejonction 
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Figure 3.18 — Exemple d'etats-transitions avec point de jonction 



O 



Point de choix 



message vocal 
regu 



message mobile regu/activerA/R 



message SMS 
regu 



message mobile regu/activerA/R 



message Fax 
regu 



message Fax regu/activerA/R 




A/R mobile 



[typeMobile] 



[else] 



{ 



A/R Fax 



Figure 3.19 — Exemple d'etats-transitions avec point de choix 
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Etat historique 



La mention de l'historisation d'un etat composite permet de pouvoir indiquer la 
reutilisation du dernier etat historise en cas de besoin. 

Formalisme et exemple 

Le formalisme de representation d'etats historises est donne a la figure 3.20. 



0E 



Etat historise 




Figure 3.20 — Exemple d'etats-transitions historises 



3.2.4 Exercices 

Exercice 1 

Enonce 

Soit a representer le diagramme d'etat-transition d'un objet personnel en suivant les 
evenements de gestion depuis le recrutement jusqu'a la mise en retraite. 

Apres le recrutement, une personne est considered en activite des sa prise de 
fonction dans l'entreprise. Au cours de sa carriere, nous retiendrons seulement les 
evenements : conge de maladie et prise de conge annuel. En fin de carriere, nous 
retiendrons deux situations : la demission et la retraite. 

Corrige 

Nous proposons au lecteur un corrige type a la figure 3.21. Ce corrige ne represente 
qu'une solution parmi d'autres variantes possibles suivant la lecture faite de 
Penonce. Pour notre part, nous avons retenu les etats caracteristiques : recrute, acti- 
vite, en conge, en arret, parti et retraite. 
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retraite 



Demande de retraite [age]/mise en retraite; 
Arrivee/prise de fonction 

> 




Demission/depart 




Maladie/mise en maladie 
> 



activite 



en arret 



Retour' 
conge/mise 
en activite 



Reprise/reprise activite 
Prise de conge/mise en conge 



en conge 



Figure 3.21 — Diagramme d'etat-transition de I'exercice 1 

Exercice de synthese 

En se replagant dans I'exercice de synthese Locagite, nous allons retenir l'objet 
« Gites geres » comme support d'application du diagramme d'etat-transition. Quatre 
etats permettent de caracteriser son comportement : 

• Etat 1 : Gtte a louer 

• Etat 2 : Gite reserve 

• Etat 3 : Gite reserve ferme 

• Etat 4 : Gite reserve loue 



La figure 3.22 representee le diagramme d'etat-transition de cet objet. 
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annulation sejour 



V 




ilation sejour 



Figure 3.22 — Diagramme d'etat-transition de I'objet « Gites geres » 



3.3 DIAGRAMME D'ACTIVITE (DAC) 

3.3.1 Presentation generale et concepts de base 

Le diagramme d'activite presente un certain nombre de points communs avec le 
diagramme d'etat-transition puisqu'il concerne le comportement interne des opera- 
tions ou des cas d'utilisation. Cependant le comportement vise ici s'applique aux 
dots de controle et aux dots de donnees propres a un ensemble d'activites et non 
plus relativement a une seule classe. 

Les concepts communs ou tres proches entre le diagramme d'activite et le dia- 
gramme d'etat-transition sont : 

• transition, 

• # noeud initial (etat initial), 

• © noeud final (etat final), 

• <S> noeud de fin flot (etat de sortie), 

• 0 nceud de decision (choix). 

Le formalisme reste identique pour ces nceuds de controle. 
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Les concepts specifiques au diagramme d'activite sont : 

• nceud de bifurcation, 

• nceud de jonction, 

• nceud de fusion, 

• pin d'entree et de sortie, 

• flot d'objet, 

• partition. 



Nous avons par ailleurs reserve un traitement particulier pour les concepts action 
et activite. En effet, etant donne que ces concepts sont au cceur du diagramme 
d'activite, nous avons prefere les traiter de maniere detaillee a ce niveau alors 
qu'ils sont deja evoques dans le diagramme d'etat-transition. 



Action 

Une action correspond a un traitement qui modifie l'etat du systeme. Cette action 
peut etre apprehendee soit a un niveau elementaire proche d'une instruction en 
termes de programmation soit a un niveau plus global correspondant a une ou 
plusieurs operations. 

Formalisme et exemple 

Une action est representee par un rectangle dont les coins sont arrondis comme pour 
les etats du diagramme d'etat-transition (fig. 3.23). 



Nom de Taction 



Saisir commande 



Figure 3.23 — Formalisme et exemple d'une action 

Transition et flot de controle 

Des qu'une action est achevee, une transition automatique est declenchee vers 
Taction suivante. II n'y a done pas d'evenement associe a la transition. 

L'enchainement des actions constitue le flot de controle. 
Formalisme et exemple 

Le formalisme de representation d'une transition est donne a la figure 3.24. 



action 1 



transition 



action 2 



Figure 3.24 — Formalisme de base du diagramme d'activite : actions et transition 
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Activite 

Une activite represente le comportement d'une partie du systeme en termes 
d'actions et de transitions. Une activite est composee de trois types de nceuds : 

• nceud d'execution (action, transition), 

• nceud de controle (nceud initial, nceud final, flux de sortie, nceud de bifurca- 
tion, nceud de jonction, nceud de fusion-test, nceud de test-decision, pin 
d'entree et de sortie), 

• nceud d'objet. 

Une activite peut recevoir des parametres en entree et en produire en sortie. 
Formalisme et exemple 

Nous donnons une premiere representation simple a la figure 3.25. 




Figure 3.25 — Exemple de representation d'une activite 

Nceud de bifurcation (fourche) 

Un nceud de bifurcation (fourche) permet a partir d'un flot unique entrant de creer 
plusieurs flots concurrents en sortie de la barre de synchronisation. 

Formalisme et exemple 

Le formalisme de representation de nceud de bifurcation ainsi qu'un premier 
exemple sont donnes a la figure 3.26. Un second exemple avec nceud de bifurcation 
est donne a la figure 3.27. 
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Noeud de bifurcation 
(fourche) 




envoyer marchandise 



0 



Figure 3.26 — Exemple 1 d'activites avec nceud de bifurcation 



Lettre de refus 



Examen 
candidature 



Points 

de bifurcation 



1 



Convocation 



Preparation 
entretien technique 



Preparation 
entretien DRH 



Figure 3.27 — Exemple 2 de diagramme d'activite 
avec bifurcation de flots de controle 



Noeud de jonction (synchronisation) 

Un nceud de jonction (synchronisation) permet, a partir de plusieurs flots concur- 
rents en entree de la synchronisation, de produire un flot unique sortant. Le nceud 
de jonction est le symetrique du nceud de bifurcation. 

Formalisme et exemple 

Le formalisme de representation d'un nceud de jonction est donne a la figure 3.28. 
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Noeud de jonction 
(synchronisation) 




envoyer carte adherent 



Figure 3.28 — Exemple d'activites avec nceud de jonction 



Noeud de test-decision 

Un nceud de test-decision permet de faire un choix entre plusieurs flots sortants en 
fonction des conditions de garde de chaque flot. Un nceud de test-decision n'a qu'un 
seul flot en entree. On peut aussi utiliser seulement deux flots de sortie : le premier 
correspondant a la condition verifiee et l'autre traitant le cas sinon. 

Formalisme et exemple 

Le formalisme de representation d'un nceud de test-decision ainsi qu'un premier 
exemple sont donnes a la figure 3.29. Un second exemple avec nceud de test-deci- 
sion est donne a la figure 3.30. 




Figure 3.29 — 



Formalisme et exemple 1 d'activites avec nceud de test-decision 
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Examen 
candidature 



[Candidature rejetee] 



[Candidature retenue] 



Lettre de refus 



1 


' N 

Convocation 


Transition 


r 




Entretien 



Figure 3.30 — Exemple 2 de diagramme d'activites avec un noeud de test-decision 
Nceud de fusion-test 

Un nceud de fusion-test permet d'avoir plusieurs flots entrants possibles et un seul 
flot sortant. Le flot sortant est done execute des qu'un des flots entrants est active. 

Formalisme et exemple 

Le formalisme de representation d'un nceud de fusion-test ainsi qu'un exemple sont 
donnes a la figure 3.31. 



o 



Nceud de fusion-test 



Commander 
par telephone 



Commander 
par messagerie 




$4 Facturer 



c 



Commander 
par courrier 




Figure 3.31 — Formalisme et exemple de diagramme d'activites 
avec un nceud de fusion-test 
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Pin d'entree et de sortie 

Un pin d'entree ou de sortie represente un parametre que Ton peut specifier en 
entree ou en sortie d'une action. Un nom de donnee et un type de donnee peuvent 
etre associes au pin. Un parametre peut etre de type objet. 

Formalisme et exemple 

Chaque parametre se represente dans un petit rectangle. Le nom du parametre ainsi 
que son type sont aussi a indiquer. Le formalisme de representation de pin d'entree 
ou de sortie ainsi qu'un exemple sont donnes a la figure 3.32. 

J pin d'entree ou de sortie 




p1 : entier 
p2 : texte 
r1 : reel 



Figure 3.32 — Formalisme et exemple d'activite avec pin d'entree et de sortie 



Flot de donnees et nceud d'objet 

Un nceud d'objet permet de representer le flot de donnees vehicule entre les 
actions. Les objets peuvent se representer de deux manieres differentes : soit en utili- 
sant le pin d'objet soit en representant explicitement un objet. 

Formalisme et exemple 

Le formalisme de representation de flot de donnees et nceud d'objet est donne direc- 
tement au travers d'un exemple (fig. 3.33). 



Commander 



A 



J 



c 



commande 



commafcde 



Facturer 



Commander 





fcommandel 




► 


4 



Facturer 



Figure 3.33 — Exemple de flot de donnees et de noeud d'objets 
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Partition 

UML permet aussi d'organiser la presentation du diagramme d'activite en couloir 
d'activites. Chaque couloir correspond a un domaine de responsabilite d'un certain 
nombre d'actions. 

Les flots d'objets sont aussi representes dans le diagramme. L'ordre relatif des cou- 
loirs de responsabilite n'est pas significatif. 

3.3.2 Representation du diagramme d'activite 

Un exemple general de diagramme d'activite est donne a la figure 3.34. 




Figure 3.34 — Exemple de diagramme d'activite avec couloir d'activite 



Representation d'actions de communication 

Dans un diagramme d'activite, comme dans un diagramme de temps, des interac- 
tions de communication liees a certains types d'evenement peuvent se representer. 
Les types d'evenement concernes sont : 

• signal, 

• ecoulement du temps. 
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Formalisme et exemple 

Le formalisme de representation ainsi qu'un exemple d'actions de communication 
sont donnes a la figure 3.35. 



Signal recu 



Acceptation d'une condition 
liee au temps 



Signal envoye 



Detecter arrivee vehicule 



Actionner ouverture 



Ouvrir portes 




Faire clignoter lampe 



J 



Figure 3.35 — Formalisme et exemple de diagramme d'activite 
avec actions de communication 



3.3.3 Exercices 



Exercice 1 



En reprenant l'exercice relatif a la gestion de la bibliotheque traite dans les cas 
d'utilisation nous pouvons elaborer le diagramme d'activite correspondant. 

Deux acteurs ont ete identifies : 

• Bibliothecaire charge de Papprovisionnement des ouvrages, de la gestion du 
catalogue et de l'enregistrement des emprunts et retours d'ouvrages ; 

• Gestionnaire, charge de l'inscription des adherents et de la relance des adhe- 
rents ayant depasse le delai de restitution des ouvrages. 



La representation du diagramme d'activite est donnee a la figure 3.36. 
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Figure 3.36 — Diagramme d'activite de I'exercice 1 



Exercice de synthese 

La figure 3.37 represente le diagramme d'activite de Locagite. Ce diagramme nous 
permet de montrer, par couloir de responsabilite des acteurs internes a Locagite, les 
etats-actions executes. 
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Gestionnaire catalogue-proprietaire 



Gestionnaire reservation-location 



^enregistrer nouveau gtte ^ 



enregistrer contrat proprietaire 



c 



mettre a jour catalogue 



^mettre a jour gtte^ 
^editer catalogue ^ 



editer etat des reservations 



3 



C 



enregistrer reservations 



^editer etat contrat ^ 



enregistrer conf. contrat et acompte 



J 



c 



controler delai confirmation 




arrivee solde ] 



[ delai depasse ] 



^annuler contrat ^ 



z 



enregistrer annulation contrat 



J 




Figure 3.37 — Diagramme d'activite du cas Locagite 



3.4 DIAGRAMME DE SEQUENCE (DSE) 

3.4.1 Presentation generale et concepts de base 

L'objectif du diagramme de sequence est de representer les interactions entre objets 
en indiquant la chronologie des echanges. Cette representation peut se realiser par 
cas d'utilisation en considerant les differents scenarios associes. 
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Un diagramme de sequence se represente globalement dans un grand rectangle 
avec indication du nom du diagramme en haut a gauche comme indique a la 
figure 3.38. 



sd nom du diagramme J 



representation du diagramme 



sd : abreviation de « sequence diagramm » 
Figure 3.38 — Formalisme general du cadre d'un diagramme de sequence 



Ligne de vie 

Une ligne de vie represente l'ensemble des operations executees par un objet. Un 
message regu par un objet declenche l'execution d'une operation. Le retour d'infor- 
mation peut etre implicite (cas general) ou explicite a l'aide d'un message de retour. 

Message synchrone et asynchrone 

Dans un diagramme de sequence, deux types de messages peuvent etre distingues : 

• Message synchrone - Dans ce cas l'emetteur reste en attente de la reponse a 
son message avant de poursuivre ses actions. La fleche avec extremite pleine 
symbolise ce type de message. Le message retour peut ne pas etre represente 
car il est inclus dans la fin d'execution de Poperation de l'objet destinataire du 
message. Voir le message 1 de la figure 3.39. 

• Message asynchrone - Dans ce cas, l'emetteur n' attend pas la reponse a son 
message, il poursuit l'execution de ses operations. C'est une fleche avec une 
extremite non pleine qui symbolise ce type de message. Voir le message 2 de la 
figure 3.39. 

Formalisme et exemple 

Le formalisme est donne dans l'exemple type presente a la figure 3.39. 



3.4.2 Operations particulieres 

Creation et destruction d'objet 

Si un objet est cree par une operation, celui-ci n'apparait qu'au moment oil il est 
cree. Si l'objet est detruit par une operation, la destruction se represente par « X ». 
Un exemple type est donne a la figure 3.40. 
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sd Diagramme 1 J~ 



objetl 



: Client 



message 1() 



message 3 



objet2 



Ligne de vie 
message 2() 



message 4 



message 5() 



retour message3 



objet3 



^0 



Figure 3.39 — Formalisme du diagramme de sequence 



objet 1 : Classe 1 



Creation objet 2 



objet 2 : Classe 2 



Destruction objet 2 



Figure 3.40 — Exemple type de creation et de destruction d'objet 



II est aussi possible dans certains outils de modelisation d'indiquer plus simple- 
ment la creation d'une nouvelle instance d'objet en utilisant le mot-cle « create » 
(voir exemple dans les etudes de cas presentees a la fin de cet ouvrage). 

Contrainte temporelle 

Des contraintes de chronologie entre les messages peuvent etre specifiees. De plus lorsque 
l'emission d'un message requiert une certaine duree, il se represente sous la forme d'un 
trait oblique. Un exemple general de contrainte temporelle est donne a la figure 3.41- 

Lorsque le diagramme de sequence est utilise pour representer un sous-ensemble 
du logiciel a realiser, il est possible d'indiquer le pseudo-code execute par un objet 
pendant le deroulement d'une operation. 
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obiet 1 : Classe 1 



obiet 2 : Classe 2 



{b-a < 2 sec.} 



Figure 3.41 — Exemple type de representation de contrainte temporelle 

3.4.3 Fragment d'interaction 

Types de fragments d'interaction 

Dans un diagramme de sequence, il est possible de distinguer des sous-ensembles 
d'interactions qui constituent des fragments. 

Un fragment d'interaction se represente globalement comme un diagramme de 
sequence dans un rectangle avec indication dans le coin a gauche du nom du frag- 
ment. 

Un port d'entree et un port de sortie peuvent etre indiques pour connaitre la 
maniere dont ce fragment peut etre relie au reste du diagramme comme le montre la 
figure 3.42. Dans le cas ou aucun port n'est indique c'est l'ensemble du fragment qui 
est appele pour execution. 

Formalisme et exemple 

Dans l'exemple propose (fig. 3.42), le fragment « ControlerProduit » est represente 
avec un port d'entree et un port de sortie. 

Un fragment d'interaction dit combine correspond a un ensemble d'interaction 
auquel on applique un operateur. Un fragment combine se represente globalement 
comme un diagramme de sequence avec indication dans le coin a gauche du nom de 
l'operateur. 



Treize operateurs ont ete definis dans UML : alt, opt, loop, par, strict/weak, break, ignore/ 
consider, critical, negative, assertion et ref. 
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sd Diagramme d'ensemble y ) 



Interface 
IHM 




Client 









: Gestionnaire 



saisirCommandef ) 



1} 



contr6lerClient( ) 



seq ControlerProduit y 



Prod u it 



>ntr6lerExistenceProduit 



D 



existePSoduit( ' 



Figure 3.42 — Exemple de fragment d'interaction avec port d'entree et de sortie 



Operateur alt 

L'operateur alt correspond a une instruction de test avec une ou plusieurs alterna- 
tives possibles. II est aussi permis d'utiliser les clauses de type sinon. 

Formalisme et exemple 

L'operateur alt se represente dans un fragment possedant au moins deux parties sepa- 
rees par des pointilles. L'exemple donne (fig. 3.43) montre 1 'equivalent d'un test a 
deux conditions explicites (sans clause sinon). 

Operateur opt 

L'operateur opt (optional) correspond a une instmction de test sans alternative (sinon). 
Formalisme et exemple 

L'operateur opt se represente dans un fragment possedant une seule partie (fig. 3.44). 
Operateur loop 

L'operateur loop correspond a une instruction de boucle qui permet d'executer une 
sequence d'interaction tant qu'une condition est satisfaite. 

II est possible aussi d'utiliser une condition portant sur un nombre minimum et 
maximum d'execution de la boucle en ecrivant : loop min, max. Dans ce cas, la bou- 
cle s'executera au minimum min fois et au maximum max fois. II est aussi possible de 
combiner l'option min/max avec la condition associee a la boucle. 
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Gestionnaire 



saisirAdherent( ) 



Adherent 



Emprunt 



controlerEtat( ) 



alt EtatEmprunt } 



[etat emprunt=rendu] 



u 



autoriserEmprunt( ) 
[etat emprunt=non rendu] 



u 



refuserEmprunt( ) 



Figure 3.43 — Exemple de fragment d'interaction avec I'operateur alt 



Adherent 



Gestionnaire 



relancer( ) 



Emprunt 



opt Relancer 



testerArelancer( ) 



retourSituationRelance 



[si relance] 

relancer( ) 



Figure 3.44 — Exemple de fragment d'interaction avec I'operateur opt 



Formalisme et exemple 

L'operateur loop se represente dans un fragment possedant une seule partie et englo- 
bant toutes les interactions faisant partie de la boucle. Un exemple est donne a la 
figure 3.45. 
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Association 



Adherent 



loop EtatRetour=Non rendu et delai= depasse/' 




relancer( ) 

















Figure 3.45 — Exemple de fragment d'interaction avec l'operateur loop 



Operateur par 

L'operateur par (parallel) permet de representer deux series d'interactions qui se 
deroulent en parallele. 

Formalisme et exemple 

L'operateur par se represente dans un fragment possedant deux parties separees par 
une ligne en pointille. C'est un operateur qui est a notre avis plutot utilise dans 
l'informatique temps reel et c'est pour cela que nous ne donnerons qu'un exemple 
type (fig. 3.46). 



: Classel 




: Classe2 




: Classe3 



Traitements Al et A2 menes 1 
en parallele au traitement B3 



par ) 



traiterAl( ) 



traiterA2( ) 



traiterB3f ) 



Figure 3.46 — 



Exemple de fragment d'interaction avec l'operateur par 
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Operateurs strict et weak sequencing 

Les operateurs srict et weak permettent de representor une serie d'interactions dont 
certaines s'operent sur des objets independants : 

• L'operateur strict est utilise quand l'ordre d'execution des operations doit etre 
strictement respecte. 

• L'operateur weak est utilise quand l'ordre d'execution des operations n'a pas 
d'importance. 

Formalisme et exemple 

L'exemple presente figure 3.47 montre que les operations Al, A2, Bl, B2 et A3 
doivent etre executees dans cet ordre puisqu'elles font partie du fragment d'interac- 
tion comportant l'operateur strict. 



: Classel 




: Classe2 




: Classe3 




: Classe4 

























7 




strict 



traiterAl( ) 



traiterA2( ) 



traiterA3( ) 



traiterB2( ) 



Figure 3.47 — Exemple de fragment d'interaction avec l'operateur strict 



Operateur break 

L'operateur break permet de representer une situation exceptionnelle correspondant 
a un scenario de rupture par rapport au scenario general. Le scenario de rupture 
s'execute si la condition de garde est satisfaite. 

Formalisme et exemple 

L'exemple presente figure 3.48 montre que les operations annulerOpl( ), 
annulerOp2( ) et afficherAide( ) ne seront executees que si la touche Fl est activee 
sinon le fragment est ignore et la sequence de traitement passe directement de 
l'operation Op2( ) a l'operation Op3( ). 
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sd Exemple break ^7" 



: Classel 




: Classe2 




opin 





Classe3 



13 



Op2() 



Tl 



break [Fl]/ " 



annulerOpl( ) 



afficherAide( ) 



annulerOp2( ) 



13 



Op3() 



Figure 3.48 — Exemple de fragment d'interaction avec I'operateur break 



Operateurs ignore et consider 

Les operateurs ignore et consider sont utilises pour des fragments d'interactions dans 
lesquels on veut montrer que certains messages peuvent etre soit absents sans avoir 
d'incidence sur le deroulement des interactions (ignore), soit obligatoirement 
presents (consider). 

Formalisme et exemple 

L'exemple presente figure 3.49 montre que : 

• dans le fragment consider, les messages Opl, Op2 et Op5 doivent etre obliga- 
toirement presents lors de l'execution du fragment sinon le fragment n'est pas 
execute, 

• dans le fragment ignore, les messages Op2 et Op3 peuvent etre absents lors de 
l'execution du fragment. 

Operateur critical 

L'operateur critical permet d'indiquer qu'une sequence d'interactions ne peut etre 
interrompue compte tenu du caractere critique des operations traitees. On considere 
que le traitement des interactions comprises dans la sequence critique est atomique. 

Formalisme et exemple 

L'exemple presente figure 3.50 montre que les operations Opl( ), Op2( ) et Op3( ) 
du fragment critical doivent s'executer sans interruption. 
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sd Exemple consider et ignorep" 



: Classel 




: Classe2 




: Classe3 













consider {Opl,Op2,Op5) > J 



QpiQ 



Op5() 



0p2() 



0p3() 



"tl 



*0 



ignore{Op2,Op3} / ^~ 



Op2() 



Op5() 



Tl 



Classe4 



0p3() 



~0 



Figure 3.49 — Exemple de fragment d'interaction 
avec les operateurs ignore et consider 
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sd Exemple operateur critical 



Classel 



Classe2 



Classe3 



critical 



tr 



QpiQ 



Op3() 



Op2() 



Figure 3.50 — 



Exemple de fragment d'interaction avec I'operateur critical 
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Operateur negative 

L'operateur neg (negative) permet d'indiquer qu'une sequence d'interactions est 
invalide. 

Formalisme et exemple 

L'exemple presente figure 3.51 montre que les operations Opl( ) et Op2( ) du frag- 
ment neg sont invalides. Une erreur sera declenchee dans ce cas a l'execution du 
fragment. 



sd Exemple operateur negative 



: Classel 




: Classe2 




: Classe3 













"eg ) 




Figure 3.51 — Exemple de fragment d'interaction avec l'operateur neg 
Operateur assertion 

L'operateur assert (assertion) permet d'indiquer qu'une sequence d'interactions est 
l'unique sequence possible en considerant les messages echanges dans le fragment. 
Toute autre configuration de message est invalide. 

Formalisme et exemple 

L'exemple presente figure 3.52 montre que le fragment assert ne s'executera que si 
l'unique sequence de traitement Opl( ), Op2( ) et Op3( ) se realise en respectant 
l'ensemble des caracteristiques de ces operations (parametre d'entree, type de 
resultat...). Toute autre situation sera consideree invalide. 

Operateur ref 

L'operateur ref permet d'appeler une sequence d'interactions decrite par ailleurs 
constituant ainsi une sorte de sous-diagramme de sequence. 

Formalisme et exemple 

L'exemple presente figure. 3.53 montre que Ton fait appel a un fragment « Controle 
des droits » qui est decrit par ailleurs. 
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Classel 



Classe2 



Classe3 



sd Exemple operateur assert 



assert J~ 



Opl() 



0p2() 



Op3() 



Figure 3.52 — Exemple de fragment d'interaction avec I'operateur assert 



sd Gestion des contrats J 



2 



Gestionnaire 



: Classel 




: Classe2 







Classe3 



saisieIdcontrat( ^^ontr6lerdroitContrat( ^ 




Figure 3.53 — Exemple de fragment d'interaction avec I'operateur ref 



3.4.4 Autre utilisation du diagramme de sequence 

Le diagramme de sequence peut etre aussi utilise pour documenter un cas d'utilisa- 
tion. Les interactions entre objets representent, dans ce cas, des flux d'informations 
echanges et non pas de veritables messages entre les operations des objets. Un 
exemple de cette utilisation du diagramme de sequence est donne a la figure 3.54. 
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Scenario A 
Client X 



Representant 



Demande 



Proposition 
commande 
< 



Commande 



Commande 



Disponibilite 
articles 



Reponse 
disponibilite 



Commande 



Facture 



Facture 



Factu ration 



Figure 3.54 — Exemple de diagramme de sequence associe a un cas d'utilisation 



3.4.5 Exercices 

Exercice 1 

En se referant au sujet de l'exercice 3 du diagramme de classe, nous donnons a titre 
d'exemple, a la figure 3.55 le diagramme de sequence. Ce scenario correspond a la 
creation d'une agence integrant la creation d'une personne. 



DirectionReqionale 



1 : Creation 
d'une agence 



agence : Agence 



4 : Agence creee 



Mc- 



2 : Creation 

du directeur de I'agence 



personnel : Personnel 



3 : Directeur 
de I'agence cree 

<- 



Figure 3.55 — Exemple de diagramme de sequence de l'exercice 
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Exercice de synthese 

Nous reprenons ici les cas d'utilisation decrits dans l'exercice de synthese du DCU. 
La figure 3.56 represents le DSE du cas d'utilisation Gestion annuelle du catalogue. 
La figure 3.57 represente le DSE du cas d'utilisation Publication du catalogue. 



<boundary> 
IHM 



: Gestionnaire catalogue 

creationGTte( ) 



Proprietaire 



opt Creation proprietaire j i 



creationProprietaire( ) 



opt Traitement erreur saisj g 



affichage erreur 



opt Erreur saisie gite) 



affichage erreur 



modificationGite( ) 



Catalogue 



«create» 



si proprietaire 
n'existe pas 



eationProprietaire( 



affichage erreur 



controle >aisie( ) 



creatio iPropriet$ire( 



«create» 
creationGite( ) 



affichaqfe erreur 



opt Erreur saisie giti 



affichage erreur 



affichage erreur 



contr6JerGTte( ) 



contrdleSaisief ) 



MAJactivje( ) 



ajoutGIte( ) 



Tj 



affichage erreur 



controleProprietairei 



alt Traitement ( 



[Controle OK] 



modification OK 



[Controle non OK] 

<£ 

erreur proprietaire 



modificationGite( ) 



modifActivite( ) 



Figure 3.56 — Diagramme de sequence de la Gestion du catalogue 
de l'exercice de synthese 
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<boundary> 
IHM 



Catalogue 



Proprietaire 



Periode 
location 



: Gestionnaire catalogue proprietaire 
demandeElaborationCatalogue( ) 



loop Traitement gite J 
afficheCatalc gue(j) j afficheProprietajre( ) 



I pour tous les gite: 



afficheGTtef) i : 



afficheTa£ifSemaine( ) 



afficheActivite( } 



Figure 3.57 — Exemple de diagramme de sequence de I'exemple recapitulatif 



3.5 DIAGRAMME DE COMMUNICATION (DCO) 



3.5.1 Presentation generale et concepts de base 

Le diagramme de communication constitue une autre representation des interac- 
tions que celle du diagramme de sequence. En effet, le diagramme de communica- 
tion met plus l'accent sur l'aspect spatial des echanges que l'aspect temporel. 

Role 

Chaque participant a un echange de message correspondant a une ligne de vie dans 
le diagramme de sequence se represents sous forme d'un role dans le diagramme de 
communication. Un role est identifie par : 

<nom de role> : <nom du type> 

Une des deux parties de cette identification est obligatoire ainsi que le separateur 
« : ». Le nom du role correspond au nom de l'objet dans le cas ou l'acteur ou la classe 
ont un role unique par rapport au systeme. Le nom du type correspond au nom de la 
classe lorsque Ton manipule des objets. 

Exemple 

administrateur : utilisateur 
Pour un utilisateur qui est vu au travers de son role d'administrateur. 

Message 

Un message correspond a un appel d'operation effectue par un role emetteur vers un 
role recepteur. Le sens du message est donne par une fleche portee au-dessus du lien 
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reliant les participants au message (origine et destinataire). Chaque message est 
identifie par : 

< numero > : nom ( ) 

Plus precisement Identification d'un message doit respecter la syntaxe suivante : 

[n° du message prec. regu] « . » n° du message [clause d'iteration] [condition] 
« : » nom du message. 

• Numero du message precedent regu : permet d'indiquer la chronologie des 
messages. 

• Numero du message : numero hierarchique du message de type 1.1, 1.2... avec 
utilisation de lettre pour indiquer la simultaneity d'envoi de message. 

• Clause d'iteration : indique si l'envoi du message est repete. La syntaxe est * 
[specification de 1' iteration]. 

• Condition : indique si l'envoi du message est soumis a une condition a satis- 
faire. 

Exemples 

1.2.1 * [3 fois] pour un message a adresser trois fois de suite. 
1.2a et 1.2b pour deux messages envoyes en meme temps. 
Exemple recapitulatif de designation de message : 

1.2a.l.l[si t > 100] : lancer( ) 

Ce message signifie : 

• 1.2a : numero du message regu avant l'envoi du message courant. 

• 1.1 : numero de message courant a envoyer. 

• [si t > 100] : message a envoyer si t > 100. 

• lancer( ) : nom du message a envoyer. 

3.5.2 Formalisme et exemple 

Les roles correspondent a des objets. Le lien entre les roles est represente par un trait 
materialisant le support des messages echanges. La figure 3.58 donne le formalisme 
de base du diagramme de communication. 



objet 1 : classe 1 



Sens et identification du message 



objet 2 : classe 2 



Figure 3.58 — Formalisme de base du diagramme de communication 
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Un exemple de diagramme de communication est donne a la figure 3.59. 



sd Communication. 



7 



1- commandeDemandee( ) 



Client 


► 


Commande 







3- commandeRealisee( ) 





2- rechercheProduit( ) 



Produit 



Figure 3.59 — Exemple de diagramme de communication 



3.5.3 Exercices 

Exercice 1 



En reprenant le sujet de l'exercice 1 du diagramme de sequence, nous donnons a la 
figure 3.60 son equivalent en diagramme de communication. 



1: Creation d'une agence 



: Direction reqionale 


> 


aaence : Aaence 












4 : Agence creee 

t 

3 : Creation d'un personnel realisee | 


^2 : Creation d'un personnel de I'agence 




personnel : Personnel 





Figure 3.60 — Exemple d'ensemble du diagramme de collaboration 

3.6 DIAGRAMME GLOBAL D INTERACTION (DGI) 

3.6.1 Presentation generale et concepts de base 

Le diagramme global d'interaction permet de representer une vue generale des inte- 
ractions decrites dans le diagramme de sequence et des flots de controle decrits dans 
le diagramme d'activite. 



3.6 Diagramme global d'interaction (DGI) 
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Le diagramme global d'interaction privilegie la vue generale des flux de controle 
dans lesquels les nceuds sont des interactions ou des utilisations d'interactions (ope- 
rateur ref) . 

Autrement dit, le diagramme global d'interaction est un diagramme d'activite 
dans lequel on represente des fragments d'interaction ou des utilisations d'interac- 
tions. Ainsi, il est possible de representer : 

• des choix de fragments d'interactions (fusion) ; 

• des deroulements paralleles de fragments d'interactions (debranchement et 
jonction) ; 

• des boucles de fragments d'interaction. 

Les lignes de vie concernees par le diagramme global d'interaction peuvent etre 
citees dans l'en-tete du diagramme mais ne sont pas a representer graphiquement. 

Concepts manipules 

Le diagramme global d'interaction utilise les concepts du diagramme d'activite 
auquel on ajoute deux complements : 



• Les fragments d'interaction du diagramme de sequence - II s'agit comme le 
montre la figure 3.61 de la notion de fragment d'interaction vue dans le 
diagramme de sequence mais qui ne doit pas etre detaille a ce niveau. 




Client 



Comtnande 




commanded ) 



Figure 3.61 — Exemple de fragment d'interaction 



• Les utilisations de fragments d'interaction - II est aussi possible de faire 
appel a des fragments d'interaction a l'aide de l'operateur ref comme le montre 
la figure 3.62. 



ref 



Nom du fragment 



Figure 3.62 — Exemple de fragment d'interaction avec l'operateur ref 



108 



Chapitre 3. Les diagrammes comportementaux 



3.6.2 Representation et exemple 

La figure 3.63 donne un exemple de diagramme global d'interaction. 



sd Diagramme global lignes de vie : Utilisateur, systemeControle y~ 



ref j~ 



activer systemeControle Acces 



systemeControle 



controlerCode 



Controle non OK 



Controle OK 



systemeControle 



Message "Entrer" 




Figure 3.63 — 



Exemple de diagramme global d'interaction 



3.7 Diagramme de temps (DTP) 
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3.7 DIAGRAMME DE TEMPS (DTP) 

3.7.1 Presentation generale et concepts de base 

Le diagramme de temps permet de representer les etats et les interactions d'objets dans 
un contexte ou le temps a une forte influence sur le comportement du systeme a gerer. 

Autrement dit, le diagramme de temps permet de mieux representer des change- 
ments d'etats et des interactions entre objets lies a des contraintes de temps. 

Pour cela, le diagramme de temps utilise en plus des lignes de vie, les concepts 
suivants : 

• Des etats ou des lignes de temps conditionnees avec deux representations 
graphiques possibles. 

• Des representations propres aux aspects temporels : echelle de temps, 
con train te de duree, evenements . . . 

Concepts manipules 

Le diagramme de temps utilise trois concepts de base : 

• Ligne de vie - Elle represente Pobjet que Ton veut decrire. Elle se dessine de 
maniere horizontale. Plusieurs lignes de vie peuvent figurer dans un 
diagramme de temps. 

• Etat ou ligne de temps conditionnee - Les differents etats que peut prendre 
l'objet d'etude sont listes en colonne permettant ainsi de suivre le comporte- 
ment de l'objet ligne par ligne (une ligne pour un etat). 

• Etats lineaires - II s'agit du meme concept que le precedent, mais la represen- 
tation de la succession des etats est faite de maniere lineaire a l'aide d'un 
graphisme particulier. 

3.7.2 Representation et exemples 

Soit a representer le dispositif de chauffe d'un fer a repasser a vapeur au moment de 
sa mise en service selon les regies suivantes : 

• la pompe a eau qui remplit la chambre de chauffe s'active des que le temoin 
d'eau interne le demande ; 

• la pompe a eau se desactive des que le niveau d'eau necessaire est atteint ; 

• le chauffage de l'eau, permettant de produire la vapeur, se met en action a la 
premiere mise en service du fer a repasser des que le niveau d'eau de la cham- 
bre de chauffe est suffisant ; 

• le chauffage initial de l'eau dure 3 mm permettant ainsi de produire la vapeur. 

Dans cet exemple, nous avons deux objets a etudier : pompe a eau et chauffage de 
l'eau. Nous allons considerer pour chacun d'entre eux deux etats significatifs : active 
et desactive. 
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La figure 3.64 donne la representation du diagramme de temps en utilisant le for- 
malisme des etats « en escalier » et la figure 3.65 fournit la representation lineaire 
des etats. 
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Figure 3.64 — Exemple de diagramme de temps 
avec representation « en escalier » 
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Exemple de diagramme de temps avec representation lineaire 
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Demarche 
de developpement 



Nous proposons dans ce chapitre tout d'abord une synthese des deux principaux 
processus de developpement objet qui ont ete associes a UML. II s'agit de UP 
(Unified Process) et de RUP (Rational Unified Process). Ensuite nous presentons notre 
propre demarche de developpement UP7 qui est fondee sur UP. 



4.1 PRESENTATION D'UP 

UML n'est qu'un langage de modelisation. Nous n'avons pas aujourd'hui dans la 
norme, de demarche unifiee pour construire les modeles et conduire un projet 
mettant en ceuvre UML. Cependant les auteurs d'UML, ont decrit, dans un ouvrage 
[Jacobson2000a] le processus unifie (UP, Unified Process) qui doit etre associe a 
UML. Nous n'allons pas, dans le cadre de cet ouvrage, donner une presentation 
detaillee d'UP. Cependant il nous a paru interessant de degager les idees fondatrices 
d'UP dans le cadre d'une presentation generate. Nous allons tout d'abord expliciter 
les principes de la methode UP. Nous completerons ensuite cette presentation gene- 
rale en decrivant l'architecture a deux dimensions d'UP et ses principaux concepts, 
nous passerons aussi en revue les differentes phases d'UP, et pour finir nous detaille- 
rons les activites d'UP. 
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4.2 LES PRINCIPES D'UP 

Le processus de developpement UP, associe a UML, met en ceuvre les principes 
suivants : 

• processus guide par les cas d'utilisation, 

• processus iteratif et incremental, 

• processus centre sur l'architecture, 

• processus oriente par la reduction des risques. 

Ces principes sont a la base du processus unifie decrit par les auteurs d'UML. 

4.2.1 Processus guide par les cas d'utilisation 

L'orientation forte donnee ici par UP est de montrer que le systeme a construire se 
definit d'abord avec les utilisateurs. Les cas d'utilisation permettent d'exprimer les 
interactions du systeme avec les utilisateurs, done de capturer les besoins. 

Une seconde orientation est de montrer comment les cas d'utilisation consti- 
tuent un vecteur structurant pour le developpement et les tests du systeme. Ainsi le 
developpement peut se decomposer par cas d'utilisation et la reception du logiciel 
sera elle aussi articulee par cas d'utilisation. 

4.2.2 Processus iteratif et incremental 

Ce type de demarche etant relativement connu dans l'approche objet, il parait 
naturel qu'UP preconise l'utilisation du principe de developpement par iterations 
successives. Concretement, la realisation de maquette et prototype constitue la 
reponse pratique a ce principe. Le developpement progressif, par increment, est aussi 
recommande en s'appuyant sur la decomposition du systeme en cas d'utilisation. 

Les avantages du developpement iteratif se caracterisent comme suit : 

• les risques sont evalues et traites au fur et a mesure des iterations, 

• les premieres iterations permettent d'avoir un feed-back des utilisateurs, 

• les tests et l'integration se font de maniere continue, 

• les avancees sont evaluees au fur et a mesure de Pimplementation. 

4.2.3 Processus centre sur l'architecture 

Les auteurs d'UP mettent en avant la preoccupation de l'architecture du systeme 
des le debut des travaux d'analyse et de conception. II est important de definir le plus 
tot possible, meme a grandes mailles, l'architecture type qui sera retenue pour le 
developpement, l'implementation et ensuite le deploiement du systeme. Le vecteur 
des cas d'utilisation peut aussi etre utilise pour la description de l'architecture. 
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4.2.4 Processus oriente par la reduction des risques 

L' analyse des risques doit etre presente a tous les stades de developpement d'un 
systeme. II est important de bien evaluer les risques des developpements afin d'aider 
a la bonne prise de decision. Du fait de Papplication du processus iteratif, UP 
contribue a la diminution des risques au fur et a mesure du deroulement des itera- 
tions successives. 



4.3 LES CONCEPTS ET LES DEUX DIMENSIONS DU 
PROCESSUS UP 

4.3.1 Definition des principaux concepts et schema d'ensemble 

Le processus unifie decrit qui fait quoi, comment et quand les travaux sont realises 
tout au long du cycle de vie du projet. Quatre concepts d'UP repondent a ces 
questions : 

• Role (qui ?) 

• Activite (comment ?) 

• Artefact (quoi ?) 

• Workflow (quand ?) 

Role 

Un role definit le comportement et les responsabilites d'une ressource ou d'un 
groupe de ressources travaillant en equipe. Le role doit etre considere en termes de 
« casquette » qu'une ressource peut revetir sur le projet. Une ressource peut jouer 
plusieurs roles sur le projet. 

Par exemple sur un projet, Paul peut etre a la fois chef de projet et architecte. II 
represents deux roles au sens d'UP (fig. 4.1). 

Activite 

Les roles ont des activites qui definissent le travail qu'ils effectuent. Une activite est 
une unite de travail qu'une ressource, dans un role bien precis, peut effectuer et qui 
produit un resultat dans le cadre du projet. L' activite a un but clairement etabli, 
generalement exprimee en termes de creation ou de mise a jour d'artefacts, comme 
un modele, une classe ou un planning. Les ressources sont affectees aux activites 
selon leurs competences et leur disponibilite. 

Par exemple, les activites « planifier une iteration » et « anticiper les risques » 
sont attributes au role de chef de projet. 

Le schema de la figure 4-1 presente sur un exemple le positionnement et les liens 
entre ressources, roles et activites. 
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Artefacts 



Un artefact est un ensemble d'informations qui est produit, modifie ou utilise par le 
processus. Les artefacts sont les produits effectifs du projet. Les artefacts sont utilises 
comme input par les ressources pour effectuer une activite et sont le resultat d'output 
d'activites du processus. 

Un exemple d'artefacts rencontres au cours du projet est un planning d'une itera- 
tion ou un diagramme produit dans une activite. 




Roles 
^Chef de projet 

Architecte 



Activites 

Planifier une iteration 
Anticiper les risques 



Concevoir I'application 
Rediger le dossier d'architecture 



Figure 4.1 — Schema de positionnement des ressources, roles et activites 



Workflows 

Une enumeration de tous les roles, activites et artefacts ne constitue pas un 
processus. En effet, il est necessaire d'avoir une fagon de decrire des sequences d'acti- 
vites mesurables qui produisent un resultat de qualite et montre l'interaction entre 
les ressources. Le workflow est une sequence d'activites qui produit un resultat 
mesurable. En UML, il peut etre exprime par un diagramme de sequence, un 
diagramme de communication ou un diagramme d'activite. 

Schema d'ensemble 

UP peut etre decrit suivant deux dimensions traduites en deux axes comme le 
montre la figure 4.2 : 

• Un axe horizontal representant le temps et montrant l'aspect dynamique du 
processus. Sur cet axe, le processus est organise en phases et iterations. 

• Un axe vertical representant l'aspect statique du processus. Sur cet axe, le 
processus est organise en activites et workflows. 

4.3.2 Phases et iterations du processus (aspect dynamique) 

Le processus unifie, organise en fonction du temps, est divise en quatre phases 
successives. 

• Inception (Lancement). 

• Elaboration. 

• Construction. 

• Transition. 
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Organisation en fonction du temps : les phases et iterations 



Organisation 
en fonction 
du contenu : 
les activites 



Inception Elaboration Construction Transition 




Iterations 



Figure 4.2 — Schema d'ensemble d'UP 



Inception (Lancement) 

Cette phase correspond a 1 'initialisation du projet ou Ton mene une etude d'oppor- 
tunite et de faisabilite du systeme a construire. Une evaluation des risques est aussi 
realisee des cette phase. 

En outre, une identification des principaux cas d'utilisation accompagnee d'une 
description generate est modelisee dans un diagramme de cas d'utilisation afin de 
definir le perimetre du projet. II est possible, a ce stade, de faire realiser des maquet- 
tes sur un sous-ensemble des cas d'utilisation identifies. 

Ce n'est qu'a Tissue de cette premiere phase que Ton peut considerer le projet 
veritablement lance. 



Elaboration 

Cette phase reprend les resultats de la phase d'inception et elargit l'appreciation de 
la faisabilite sur la quasi-totalite des cas d'utilisation. Ces cas d'utilisation se retrou- 
vent dans le diagramme des cas d'utilisation qui est ainsi complete. 

Cette phase a aussi pour but d'analyser le domaine technique du systeme a deve- 
lopper afin d'aboutir a une architecture stable. Ainsi, toutes les exigences non recen- 
sees dans les cas d'utilisation, comme par exemple les exigences de performances du 
systeme, seront prises en compte dans la conception et Telaboration de Parchitec- 
ture. 

L'evaluation des risques et l'etude de la rentabilite du projet sont aussi precisees. 
Un planning est realise pour les phases suivantes du projet en indiquant le nombre 
d'iterations a realiser pour les phases de construction. 
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Construction 

Cette phase correspond a la production d'une premiere version du produit. Elle est 
done fortement centree sur les activites de conception, d'implementation et de test. 
En effet, les composants et fonctionnalites non implementes dans la phase prece- 
dente le sont ici. 

Au cours de cette phase, la gestion et le controle des ressources ainsi que l'opti- 
misation des couts representent les activites essentielles pour aboutir a la realisation 
du produit. En parallele est redige le manuel utilisateur de Papplication. 

Transition 

Apres les operations de test menees dans la phase precedente, il s'agit dans cette 
phase de livrer le produit pour une exploitation reelle. C'est ainsi que toutes les 
actions liees au deploiement sont traitees dans cette phase. 

De plus, des « beta tests » sont effectues pour valider le nouveau systeme aupres 
des utilisateurs. 

Iterations 

Une phase peut-etre divisee en iterations. Une iteration est un circuit complet de deve- 
loppement aboutissant a une livraison (interne ou externe) d'un produit executable. 

Ce produit est un sous-ensemble du produit final en cours de developpement, qui 
croit incrementalement d'iteration en iteration pour devenir le systeme final. 

Chaque iteration au sein d'une phase aboutit a une livraison executable du systeme. 

4.3.3 Activites du processus (aspect statique) 

Les activites menees a l'interieur des quatre phases sont plus classiques, car deja bien 
documentees dans les methodes existantes par ailleurs. Nous nous limiterons done a 
ne donner qu'une breve explication de chaque activite. 

Expression des besoins 

UP propose d'apprehender l'expression des besoins en se fondant sur une bonne 
comprehension du domaine concerne pour le systeme a developper et une modelisa- 
tion des procedures du systeme existant. 

Ainsi, UP distingue deux types de besoins : 

• les besoins fonctionnels qui conduisent a l'elaboration des cas d'utilisation, 

• les besoins non fonctionnels (techniques) qui aboutissent a la redaction d'une 
matrice des exigences. 

Analyse 

L'analyse permet une formalisation du systeme a developper en reponse a l'expres- 
sion des besoins formulee par les utilisateurs. L'analyse se concretise par l'elaboration 
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de tous les diagrammes donnant une representation du systeme tant statique 
(diagramme de classe principalement), que dynamique (diagramme des cas d'utilisa- 
tion, de sequence, d'activite, d'etat-transition...). 

Conception 

La conception prend en compte les choix d'architecture technique retenus pour le 
developpement et l'exploitation du systeme. La conception permet d'etendre la 
representation des diagrammes effectuee au niveau de l'analyse en y integrant les 
aspects techniques plus proches des preoccupations physiques. 

Implementation 

Cette phase correspond a la production du logiciel sous forme de composants, de 
bibliotheques ou de fichiers. Cette phase reste, comme dans toutes les autres methodes, 
la plus lourde en charge par rapport a l'ensemble des autres phases (au moins 40 %). 

7esf 

Les tests permettent de verifier : 

• la bonne implementation de toutes les exigences (fonctionnelles et techniques), 

• le fonctionnement correct des interactions entre les objets, 

• la bonne integration de tous les composants dans le logiciel. 

Classiquement, differents niveaux de tests sont realises dans cette activite : test 
unitaire, test d'integration, test de reception, test de performance et test de non- 
regression. 

Apres cette presentation d'UP et afin d'eclairer le lecteur sur les principaux pro- 
cessus de developpement actuellement utilises dans l'approche objet, nous donnons 
ci-apres une description generale de RUP. 

En son temps, la societe Rational Software (rachetee par IBM) avait developpe 
une version specifique d'UP sous le nom de RUP (Rational Unified Process), cette 
demarche a fait l'objet d'un ouvrage [Kruchten2000]. Dans la presentation qui 
suit, nous avons surtout mis l'accent sur les principaux apports de RUP par rapport 
a UP. 



4.4 LES PRINCIPAUX APPORTS DE RUP 

RUP® {Rational Unified Process) est un processus base sur une approche disciplined 
afin de bien maitriser l'assignation des taches et la responsabilisation des differents 
acteurs participant au cycle de developpement du logiciel. RUP a pour objectif prin- 
cipal de faire appliquer les bonnes pratiques de developpement aux entreprises, ce 
qui confere au produit final une meilleure qualite. 
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RUP se veut etre un modele evolutif qui doit etre configure pour pouvoir etre uti- 
lise en integrant les contraintes, les specificites et Phistorique de l'organisation qui 
l'adopte. 

Nous allons presenter les principaux apports de RUP par rapport a UP en traitant 
les points suivants : 

• les bonnes pratiques, 

• les phases du processus, 

• les activites du processus. 

4.4.1 Les bonnes pratiques 

RUP adhere a six bonnes pratiques de developpement observees dans l'industrie 
pour leurs succes. Sur ces six bonnes pratiques, trois sont issues des principes d'UP : 

• Developpement iteratif et incremental. 

• Developpement pilote par les cas d'utilisation. 

• Forte importance de l'architecture. 

Trois autres bonnes pratiques ont ete introduites par RUP : 

• Modelisation visuelle. 

• Verification continue de la qualite. 

• Controle des changements du logiciel. 

Modelisation visuelle 

RUP preconise Putilisation d'un langage de modelisation standard comme UML qui 
permet aux membres de l'equipe de developpement de communiquer sans ambi- 
gu'ite. 

L'utilisation d'outils de modelisation visuelle est fortement recommandee par 
RUP. Ceux-ci permettent de modeliser l'architecture et ses composants a l'aide de 
diagrammes. De plus, ils facilitent la gestion des modeles de RUP et contribuent a 
maintenir la coherence entre les differentes phases du processus : de l'expression des 
besoins a l'implementation. En resume, la modelisation visuelle permet de gerer la 
complexite des logiciels. 

Verification continue de la qualite 

RUP met l'accent sur l'importance d'evaluer continuellement la qualite d'un 
systeme du point de vue des fonctionnalites, de la fiabilite et de la performance. Pour 
cela, RUP vous assiste dans la planification, la conception, l'implementation et 
l'execution des tests adequats. 

Ces tests sont realises tout au long du processus, dans toutes les activites, en 
impliquant tous les acteurs, et en utilisant des criteres et des mesures objectifs (ex. 
tests d'integration continus). 
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Controle des changements du logiciel 

RUP propose une coordination des activites et des livrables des equipes afin de gerer 
activement les changements du logiciel. Pour cela le processus organise les activites 
en enchainement d'activites (workflows). Ces workflows decrivent comment 
controler, suivre et mesurer les changements du logiciel. De plus, ils permettent une 
meilleure allocation des ressources basee sur les priorites et les risques du projet et 
facilitent la gestion du travail sur ces changements au travers des iterations. 
Combinee au developpement iteratif, cette technique permet de controler les chan- 
gements de sorte qu'il soit possible de decouvrir rapidement les eventuels problemes 
et d'y reagir. 

4.4.2 Les phases et les activites du processus 

Comme UP, RUP est un processus a deux dimensions. II est modelise par un schema 
articule suivant deux axes (fig. 4.3) : 

• L'axe horizontal representant le temps et montrant les phases et les iterations 
du processus, 

• L'axe vertical representant l'aspect statique du processus. Les activites sont 
representees sur cet axe, RUP propose neuf activites (quatre de plus que le 
processus UP). 



Enchainement 
d'activites 

1 Modelisation metier 

2 Gestion des exigences 

3 Analyse et conception 

4 Implementation 

5 Test 

6 Deploiement 

7 Gestion de la conf. 
et des changements 

8 Gestion de projet 

9 Environnement 



Figure 4.3 — Schema d'ensemble de RUP 

Les phases et les jalons 

Les phases dans le processus RUP sont les memes que celles du processus UP. Le 
concept de jalon est introduit par RUP. Chaque phase est conclue par un jalon. Ce 
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jalon est constitue d'un ensemble de criteres d'evaluation. Ces criteres doivent etre 
satisfaits pour passer a la phase suivante. La figure 4-4 illustre les differents jalons au 
cours du processus. 



LCO . „ L p A t Capacite PR 

Objectifs Architecture operationnelle Livraison 

du cycle de vie du cycle de vie ini(ia|e du produit 

II II 

Lancement Elaboration Construction Transition | 



temps 



Figure 4.4 — Les phases et jalons dans RUP 



Le jalon LCO 

La phase de lancement se termine par le jalon « Objectifs du cycle de vie ». Ce jalon 
permet de s'assurer que les criteres suivants sont bien pris en compte par le projet : 

• Les exigences fondamen tales, les caracteristiques cles et les contraintes princi- 
pales sont documentees. 

• Etude de rentabilite definie et approuvee. 

• Estimation de charge realiste, phases identifiees, priorites definies et risques 
definis. 

• Planning de phase d'elaboration defini. 

• Perimetre defini. 

Le jalon LCA 

La phase d'elaboration se termine par le jalon « Architecture du cycle de vie ». Ce 
jalon permet de s'assurer que les criteres suivants sont bien appliques dans le projet : 

• Un ou plusieurs prototypes ont ete realises pour explorer les fonctionnalites 
critiques et les scenarios architecturalement significatifs. 

• Architecture du projet definie et stable. 

• Risques definis et pris en compte dans l'architecture. 

• Planning des phases suivantes detaille et precis. 

Le jalon IOC 

La phase de construction se termine par le jalon « Capacite operationnelle 
initiate ». Ce jalon permet de s'assurer que les criteres suivants sont bien appliques 
dans le projet : 

• Version du produit assez stable et mature pour etre fournie au client. 

• Les tests sont etablis et developpes pour valider les versions executables. 
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• Les clients sont prets a accueillir le produit. 

• Les risques sont maitrises. 

• Le plan d'iteration pour la phase de transition est complete et verifie. 
Le jalon PR 

La phase de transition se termine par le jalon « Livraison du produit ». Ce jalon 
permet de s'assurer que les criteres suivants sont bien appliques dans le projet : 

• Le produit complet et acheve en accord avec les exigences du client est deploye. 

• Le client est satisfait. 

• Les depenses du projet correspondent aux depenses prevues. 
Les activites 

Les activites de RUP, decrites ci-apres, sont celles qui sont nouvelles par rapport a 
UP. Les autres activites sont deja decrites dans UP. 

Modelisation metier 

La modelisation metier permet de mieux comprendre la structure et la dynamique 
de l'organisation etudiee. Elle assure au client que les utilisateurs finaux et les deve- 
loppeurs partagent une vision commune de l'organisation. Elle permet d'aboutir a 
une cartographie des processus metier de l'organisation cliente. 

Gestion des exigences 

La gestion des exigences a pour but de definir ce que doit faire le systeme. Pour cela, 
les cas d'utilisation sont realises. lis permettent aussi de structurer les documents de 
specifications fonctionnelles. Les cas d'utilisation sont en effet decomposes en 
scenarios d'usage du systeme dans lesquels l'utilisateur decrit ce qu'il fait grace au 
systeme et ses interactions avec le systeme (description detaillee des cas d'utilisa- 
tion). 

Les exigences non fonctionnelles (performances, qualites...) peuvent aussi etre 
decrites dans un document complementaire de specification. 

Deploiement 

Le but de l'enchainement des activites de deploiement est de livrer le produit aux 
utilisateurs finaux. Cela inclut de nombreuses sous-activites : 

• Packaging du logiciel. 

• Livraison du logiciel. 

• Migration des donnees existantes (dans certains cas). 

• Installation du logiciel. 

• Assistance aux utilisateurs. 

Ces sous-activites sont realisees pour la plupart lors de la phase de transition. 
Neanmoins, un certain nombre d'entre elles doivent etre preparees lors de la phase 
de construction comme par exemple le packaging du logiciel. 
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Gestion de la configuration et du changement 

L'objectif de la gestion de la configuration et des changements est de garder la trace 
de tous les elements tangibles qui participent au developpement et de suivre leur 
evolution. 

Pour cela, il faut traiter les points suivants : 

• Identifier les elements en configuration du projet. 

• Controler les modifications de ces elements via un outil de gestion de configu- 
ration. 

• Gerer les configurations de ces elements au cours du processus de developpe- 
ment du logiciel a l'aide d'espaces de travail (espace de developpement, 
espace d'integration et espace de livraison) . 

• Gerer les changements des elements en configuration du projet a l'aide de 
demandes de changement. Celles-ci sont utilisees pour documenter et tracer 
les anomalies, les demandes devolution et tout type de requete entrainant 
une modification du produit. Elles assurent que les impacts des modifications 
sont pris en compte a tous les niveaux. 

• Auditer la mise en place de l'activite de gestion de configuration et du chan- 
gement. 

La gestion de configuration est realisee tout au long du projet. La gestion du chan- 
gement s'applique principalement dans les phases de construction et de transition. 

Gestion de projet 

La gestion d'un projet logiciel est l'art de mesurer les objectifs competitifs, de gerer 
les risques et les contraintes pour fournir un produit qui satisfait les besoins exprimes 
par les utilisateurs. 

Pour cela, RUP insiste sur Paspect iteratif du processus de developpement et four- 
nit un cadre de travail deja documente par : 

• un framework pour la gestion d'un projet logiciel, 

• des conseils pour la planification, Pallocation des ressources, la prise de deci- 
sion et le suivi de projet, 

• un framework pour gerer les risques. 

Cette approche permet d'augmenter les chances de succes du projet. 
Environnement 

La gestion de l'environnement consiste a mettre en place tout ce qui permet aux 
differents acteurs/roles de realiser au mieux leurs activites. Ce qui revient a fournir a 
l'organisation, l'environnement de developpement - tant processus qu'outils - qui 
va aider l'equipe de developpement. 

Cet environnement peut etre adapte pour chaque projet. Ainsi RUP fournit des 
modeles et des outils facilement adaptables aux differents types de projet. 
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4.5 DEMARCHE DE DEVELOPPEMENT UP7 

4.5.1 Presentation generate 

Schema d'ensemble 

Nous proposons ici une demarche d' application d'UML qui prend appui sur UP mais 
qui se veut avant tout etre pragmatique. Cette demarche est fondee d'une part sur 
notre vision du processus de developpement et d'autre part sur notre propre expe- 
rience tiree de la realisation en entreprise de projets avec UML. 

La demarche que nous proposons est articulee suivant deux axes : les quatre pha- 
ses qui correspondent a celles d'UP et sept activites. Ainsi, on peut presenter des ce 
stade un premier schema d'ensemble de la demarche suivant ces deux axes (fig. 4.5). 



PHASES 
ACTIVITESY 


Lancement 


Elaboration 


Construction 


Transition 


1- Moderation metier 










2- Exigences 
fonctionnelles 










3- Analyse 

des cas d'utilisation 










4- Synthese 
de I'analyse 










5- Conception 










6- Implementation 










7- Test 















Figure 4.5 — Schema d'ensemble de la demarche UP7 



Le grise sur le schema represente l'effort a consentir pour chaque activite durant 
les phases d'un projet. Ainsi par exemple, pour l'activite 3 (Analyse des cas d'utilisa- 
tion), l'activite commence legerement lors de la phase de lancement puis se deroule 
principalement lors de la phase d'elaboration et se termine en phase de construction. 
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II est a noter que sur le schema, la proportion que represente chaque activite par 
rapport a l'ensemble de la charge de developpement d'un projet a ete respectee gra- 
phiquement. 

Compte tenu de notre experience et des ratios habituellement constates dans la 
profession, nous avons retenu la repartition indicative suivante pour les volumes 
d'effort a consentir sur les activites d'un projet. 

• Modelisation metier : 5 %. 

• Exigences fonctionnelles : 5 %. 

• Analyse des cas d'utilisation : 20 %. 

• Synthese de l'analyse : 5 %. 

• Conception : 10 %. 

• Implementation : 40 %. 

• Test : 15 %. 

II importe bien entendu, de tenir compte pour chaque projet de ses specificites en 
termes par exemple de complexite fonctionnelle, contraintes techniques, et compe- 
tence des ressources affectees. 

Les activites 6 et 7, « Implementation » et « Tests », sont presentes sur notre 
schema pour couvrir a ce niveau la totalite des activites en reference a UP, mais elles 
ne sont pas traitees dans l'ouvrage. 

Cette demarche est par definition iterative. II est ainsi possible, si necessaire, de 
traiter des iterations a Pinterieur de chaque phase. Chaque iteration doit se con- 
clure par un produit livrable sous forme de maquette ou de prototype. 
Des iterations successives permettent d'affiner les resultats de chaque phase. 

Activite 1 - Modelisation metier 

La premiere activite de la demarche consiste a mieux connaitre et comprendre les 
processus dans lesquels va s'integrer le futur systeme informatique. Cette activite 
aboutit a trois resultats : 

• Au positionnement du systeme a etudier au sein de l'ensemble des processus 
de l'entreprise et a la definition du perimetre fonctionnel global du systeme 
(schema de contexte du domaine d'etude). 

• A la definition des processus metiers concerned par le systeme a developper et 
a l'identification des acteurs (diagramme d' activite). 

• A la definition des concepts metiers du domaine sous forme de classe 
(diagramme de classe metier). Les concepts metiers correspondent aux infor- 
mations creees, transformees ou manipulees par les experts du domaine. 
L'expert du domaine y retrouve le vocabulaire de son metier. 

A Tissue de cette activite, le perimetre du systeme a etudier est defini. 
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Activite 2 - Exigences fonctionnelles 

La deuxieme activite de la demarche a pour but de definir ce que doit faire le systeme 
d'un point de vue metier. Cette activite permet d'obtenir trois resultats : 

• La definition des cas d'utilisation metier et leur description generale 
(diagramme de cas d'utilisation systeme). 

• Les scenarios des cas d'utilisation metier (diagramme de sequence systeme). 

• La navigation generale du systeme a etudier, c'est-a-dire l'interface homme- 
machine (schema de navigation generale). 

Au terme de ces deux premieres activites, l'expression des besoins (au sens UP) 
est couverte. 

Activite 3 - Analyse des cas d'utilisation 

La troisieme activite de la demarche a pour but de fournir une vue informatique du 
systeme. Cette activite permet d'obtenir cinq resultats : 

• La definition de tous les cas d'utilisation (metiers + informatiques) et leur 
description detaillee (diagramme des cas d'utilisation). 

• L'identification des scenarios pour chaque cas d'utilisation (diagramme de 
sequence). 

• Les differents etats des objets etudies (diagramme d'etat- transition). Cette 
partie de Pactivite est optionnelle et s'applique selon les systemes etudies. 

• Les interfaces utilisateur pour chaque cas d'utilisation. 

• Les classes pour chaque cas d'utilisation (diagramme de classe). 

A Tissue de cette activite, l'analyse des cas d'utilisation est produite mais non 
encore consolidee ni validee definitivement. 

Activite 4 - Synthese de /'analyse 

La quatrieme activite de la demarche consiste a consolider et valider toute l'analyse 
des cas d'utilisation. Cette activite permet d'obtenir deux resultats : 

• Le regroupement de Tensemble des classes en un seul diagramme (diagramme 
de classe recapitulatif). 

• La validation de l'analyse de chaque cas par le biais d'une matrice de valida- 
tion. Celle-ci permet de verifier que l'analyse des cas est complete, c'est-a-dire 
que tous les cas d'utilisation metier ont ete repris dans l'analyse. 

Au terme des activites 3 et 4, l'analyse (au sens activite UP) est couverte. 
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Activite 5 - Conception 

La cinquieme activite de la demarche se concentre sur le « comment faire ». Elle a 
pour but de definir et de mettre en place les choix d'architecture technique, et de 
completer la description du systeme sous Tangle technique. Cette activite permet 
d'obtenir quatre resultats : 

• Les choix techniques retenus. 

• Les scenarios techniques par cas d'utilisation (diagrammes de sequence tech- 
nique). 

• Les classes techniques par cas d'utilisation (diagrammes de classe technique). 

• Le regroupement sous forme de paquetage de l'ensemble des classes techni- 
ques en un seul diagramme (diagramme de paquetage). 

De ce fait la conception preliminaire est couverte par cette activite. La concep- 
tion detaillee qui est la traduction des scenarios et classes techniques dans les solu- 
tions technologiques retenues n'est pas traitee dans cet ouvrage. 

Cette activite couvre la conception (au sens UP). 

Les activites 6 et 7, « Implementation » et « Tests » se referent aux activites 
d'UP, mais ne sont pas traitees dans l'ouvrage. 

Schema de la demarche 

Pour illustrer la description generale des activites de la demarche, la figure 4.6 
presente chaque activite avec ses differentes sous-activites. Une sous-activite 
aboutit a Pelaboration d'un ou plusieurs diagrammes UML ou d'un schema de 
support au developpement du systeme (hors UML). A chaque sous-activite est asso- 
ciee une fiche guide qui est ensuite detaillee. 
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1 - Modelisation metier 

1.1 - Elaboration du schema de contexte du domaine d'etude (FG1) 

1 .2 - Elaboration du diagramme d'activite (FG2) 

1.3- Elaboration du diagramme de classe metier (FG3) 

i 

2 - Exigences fonctionnelles 

2.1 - Elaboration du diagramme des cas d'utilisation systeme (FG4) 

2.2 - Elaboration des diagrammes de sequence systeme (FG5) 

2.3 - Elaboration du schema de navigation generale (FG6) 



I 

3 - Analyse des cas d'utilisation 

3.1 - Elaboration du diagramme des cas d'utilisation (FG7) 

3.2 - Description des cas d'utilisation (FG8) 

3.3 - Elaboration des diagrammes de sequence (FG9) 

3.4 - Elaboration des diagrammes d'etat-transition (FG10) 

3.5 - Elaboration des interfaces utilisateur (FG1 1 ) 

3.6 - Elaboration des diagrammes de classe (FG12) 



i — 

4 - Synthese de I'analyse 

4.1 - Elaboration du diagramme de classe recapitulatif (FG13) 

4.2 - Elaboration de la matrice de validation (FG14) 

4 

5 - Conception 

5.1 - Realisation des choix techniques (FG15) 

5.2 - Elaboration des diagrammes de sequence technique (FG16) 

5.3 - Elaboration des diagrammes de classe technique (FG17) 

5.4 - Elaboration du diagramme de paquetage (FG18) 



4 

6 - Implementation 

Activite non traitee dans cet ouvrage 

4 

7 - Tests 

Activite non traitee dans cet ouvrage 



Figure 4.6 — 



Schema detaille de la demarche 
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4.5.2 Description des activites (fiche guide par sous-activite) 

Nous proposons au lecteur une description de la demarche a l'aide de fiches guides 
(FG). Un plan standard a ete adopte pour la presentation de ces fiches. Ce plan 
traite : l'objectif, le point de depart, le point d'arrivee, la demarche d'elaboration et 
les recommandations. 

Ces fiches peuvent etre reprises et adaptees pour chaque projet compte tenu de 
son contexte et de ses particularites. 

Modelisation metier 



FICHE GUIDE - FG1 


Activite 1 : Modelisation metier 
Sous-activite 1.1 : 

Elaboration du schema de contexte du domaine d'etude 


Projet : 


Date : 


Objectif 


Positionner le systeme a etudier au sein des processus de I'entreprise. 


Point de depart 


Esquisse fonctionnelle du besoin exprime. 


Point d'arrivee 


Systeme a etudier positionne par rapport aux processus de I'entreprise et 
perimetre fonctionnel defini. 


Demarche d'elaboration 


1 Identifier les processus connexes au systeme etudie. 

2 Determiner les interactions entre les processus connexes et le systeme etudie. 

3 Preciser le perimetre du systeme a etudier (definition des sous-ensembles fonctionnels). 


Recommandation : 

Mettre en evidence le sous-ensemble a etudier (sous-ensemble grise/mis en pointille) dans le 
schema de contexte. 
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FICHE GUIDE - FG2 



Activite 1 : Moderation metier 



Projet : 



Sous-activite 1 .2 : 

Elaboration du diagramme d'activite 



Date : 



Objectif 



Decrire les processus metiers du systeme a etudier. 



Point de depart 



Systeme a etudier positionne par rapport aux processus de I'entreprise et 
perimetre fonctionnel defini. 



Point d'arrivee 



Acteurs identifies et processus metiers du systeme etudie definis (flot de 
controle, flot de donnees...) dans le DAC. 



Demarche d'elaboration 



1 Identifier les acteurs internes et externes du systeme etudie. 

2 Identifier des actions du processus. 

3 Definir le flot de controle (enchainement des actions ) : 

- transitions automatiques, 

- transitions gardees, 

- synchronisation, 

- debut/fin du flot. 

4 Representer les donnees liees aux actions. Ces donnees sont decrites a I'aide des concepts 
du domaine. Ces concepts permettent d'initialiser le diagramme de classe metier. 

5 Determiner le flot de donnees c'est-a-dire I'enchainement des donnees entre elles et/ou avec 
des actions. 

6 Decrire les roles des acteurs du systeme. 



Recommandations : 

Veiller a la lisibilite du DAC : 

- Limiter le nombre d'activites-actions representees soit en privilegiant celles qui sont 
structurantes, soit en utilisant une presentation a plusieurs niveaux. 

- Essayer dans la mesure du possible de tracer des flots faciles a lire (eviter les traits obliques). 
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FICHE GUIDE - FG3 


Activite 1 : Moderation metier 
Sous-activite 1.3 : 

Elaboration du diagramme de classe metier 


Projet : 


Date : 


Objectif 


Definir les concepts metiers du domaine sous forme de classe. 


Point de depart 


Acteurs identifies et processus metiers du systeme etudie definis (flot de 
controle, flot de donnees). 


Point d'arrivee 


Concepts metiers identifies definis dans le DCL metier et le glossaire 
metier. 


Demarche d'elaboration 


1 Identifier les concepts du domaine sous forme de classes en prenant comme base ceux 
definis dans le diagramme d'activite. 

2 Preciser les principaux attributs utiles a la comprehension des experts metiers. 

3 Determiner les relations entre les classes : 

- nom de I'association, 

- multiplicite. 

4 Decrire de maniere generale les concepts du domaine afin d'obtenir un glossaire metier. 


Recommandations : 

1 Se limiter a ce niveau aux concepts structurants pour le systeme a etudier. 

2 Elaborer en synthese un dossier de modelisation metier. 
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FICHE GUIDE - FG4 



Activite 2 : Exigences fonctionnelles 
Sous-activite 2.1 : 

Elaboration du diagramme des cas d'utilisation systeme 


Projet : 


Date : 


Objectif 


Recueillir et decrire les besoins metiers des acteurs du systeme 
(boite noire). 


Point de depart 


Concepts metiers identifies et definis dans le DCL metier et le glossaire 
metier. 


Point d'arrivee 


Besoins metiers recueillis sous la forme de cas d'utilisation (DCU systeme) 
et decrits de maniere generale. 


Demarche d'elaboration 



1 Identifier les acteurs metiers* du systeme (acteurs internes et acteurs et/ou systemes 
externes) en prenant comme base ceux definis dans le DAC. 

2 Identifier les cas d'utilisation metiers**. 

3 Representer les interactions entre les acteurs metiers et les cas d'utilisation metiers. 

4 Definir les dependances entre les cas d'utilisation metiers. 

5 Decrire de maniere generale les cas d'utilisation metiers. 



(*) Les acteurs metiers identifies lors de cette etape sont ceux correspondant a une vue metier 
du systeme. 

(**) Les cas d'utilisation identifies lors de cette etape sont ceux correspondant a une vue metier 
du systeme. 



Recommandations : 

1 Utiliser des verbes pour decrire les cas d'utilisation. 

2 II est bon de se limiter a moins d'une dizaine de cas d'utilisation a ce niveau la. 
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FICHE GUIDE - FG5 


Activite 2 : Exigences fonctionnelles 
Sous-activite 2.2 : 

Elaboration des diagrammes de sequence systeme 


Projet : 


Date : 


Objectif 


Definir les interactions entre les acteurs metiers et le systeme (boite noire) 
pour tous les cas d'utilisation metiers. 


Point de depart 


Besoins metiers recueillis sous la forme de cas d'utilisation et decrits de 
maniere generale. 


Point d'arrivee 


Interactions entre acteurs metiers et systeme definis dans le DSE. 


Demarche d'elaboration 


Pour chaque cas d'utilisation (CU) : 

1 Reporter le ou les acteurs du CU selectionne sur le diagramme de sequence systeme (DSE). 

2 Representer le systeme sous forme d'objet. 

3 Determiner les messages echanges entre les acteurs et le systeme (synchrones, asynchrones, 
resultats). 

4 Representer les fragments d'interaction combines si necessaire (loop, alt, opt...). 


Recommandation : 

Ne pas chercher, dans cette activite, a decrire le detail des interactions entre les objets du 
systeme. 
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FICHE GUIDE - FG6 


Activite 2 : Exigences fonctionnelles 
Sous-activite 2.3 : 

Elaboration du schema de navigation generale 


Projet : 


Date : 


Objectif 


Determiner la cinematique des ecrans du systeme. 


Point de depart 


Interactions entre acteurs et systeme definies pour les cas d'utilisation 
metiers. 


Point d'arrivee 


L'interface homme-machine generale definie. 


Demarche d'elaboration 


1 Identifier les principaux ecrans provenant des cas d'utilisation metiers et des interactions 
decrites dans le DSE systeme. Les ecrans correspondent aux etats du schema de navigation 
generale si Ton utilise un diagramme d'etat-transition pour la representation de la navigation. 

2 Preciser les evenements/conditions associes a la transition entre les ecrans. 

3 Indiquer I'etat debut/fin si necessaire. 


Recommandation : 

Se limiter a une premiere vue generale de I'enchainement des ecrans correspondant a la 
vision metier. 
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FICHE GUIDE - FG7 


Activite 3 : Analyse des cas d'utilisation 
Sous-activite 3.1 : 

Elaboration du diagramme des cas d'utilisation 


Projet : 


Date : 


Objectif 


Definir la totalite des cas d'utilisation (metiers et informatiques). Les cas 
d'utilisation informatiques sont des fonctions complementaires qui n'ont 
pas ete identifies lors de I'activite precedente (ex. un module 
d'administration). 


Point de depart 


Besoins metiers, interactions acteurs metiers/systeme, IHM definies. 


Point d'arrivee 


Tous les cas d'utilisation definis dans le DCU. 


Demarche d'elaboration 


1 Identifier tous les acteurs du systeme en prenant comme base ceux definis dans le DCU 
systeme de I'activite precedente. Les acteurs informatiques apparaissent a ce niveau de 
I'analyse (ex. Administrateur d'une application). 

2 Identifier tous les cas d'utilisation en prenant comme base ceux definis dans le DCU systeme 
de I'activite precedente. Ceux-ci sont souvent decomposes a un niveau plus detaille. Les cas 
d'utilisation informatiques apparaissent a ce niveau de I'analyse. 

3 Representer les interactions entre les acteurs et les cas d'utilisation. 

4 Definir les dependances entre les cas d'utilisations. 


Recommandation : 

Veiller a limiter le nombre de cas d'utilisation. Ne pas depasser la dizaine par niveau de 
description. 
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FICHE GUIDE - FG8 



Activite 3 : Analyse des cas d'utilisation 



Projet : 



Sous-activite 3.2 : 

Description des cas d'utilisation 



Date : 



Objectif Decrire de maniere textuelle et detaillee les cas d'utilisation. 



Point de depart Tous les cas d'utilisation definis. 



Point d'arrivee Cas d'utilisation decrits de maniere textuelle. 



Demarche d'elaboration 



Pour chaque cas d'utilisation (CU) : 
1 Identifier I'objectif du CU. 



2 Identifier les acteurs du CU a partir du DCU de la sous-activite precedente. 

3 Definir les pre conditions et eventuellement post conditions du CU. 

4 Decrire le scenario nominal sous forme de liste d'actions avec une numerotation 
chronologique (1- Action 1, 2- Action 2...). L'objectif du CU doit etre atteint au terme du 
scenario. 



5 Decrire le(s) scenario(s) alternatif(s) sous forme de liste d'actions avec une numerotation 
chronologique le reliant au scenario nominal (1a : titre 1, Cas alternatif « a » de I'etape 1 du 
scenario nominal). Le(s) scenario(s) alternatif(s) doit s'achever par la satisfaction ou I'abandon 
de l'objectif. 



Recommandations : 

1 Pour le scenario nominal : 

- Utiliser 3 a 9 actions. 

- Eviter de faire apparaitre les details de I'lHM dans les actions. 

- Utiliser des phrases courtes et simples pour les actions. 

- Ne pas utiliser les « si ... sinon » dans les actions. 

2 Pour le scenario alternatif : 

- Terminer celui-ci par une action de ce type : « le CU se termine ... » ou le « le CU reprend 
au point N ... ». 
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FICHE GUIDE - FG9 


Activite 3 : Analyse des cas d'utilisation 
Sous-activite 3.3 : 

Elaboration des diagrammes de sequence 


Projet : 


Date : 


Objectif 


Representer les interactions entre les acteurs et les objets du systeme pour 
tous les cas d'utilisation en considerant les differents scenarios decrits. 


Point de depart 


Cas d'utilisation decrits de maniere textuelle et concepts metiers identifies 
et definis. 


Point d'arrivee 


Interactions entre acteurs et objets du systeme decrits dans le DSE pour 
tous les cas d'utilisation. 


Demarche d'elaboration 


Pour chaque cas d'utilisation (CU) et chaque scenario identifie : 

1 Reporter le ou les acteurs du DCU impliques dans le scenario. 

2 Representer les objets du systeme impliques dans le scenario en prenant comme base ceux 
identifies lors de I'activite de moderation metier. 

3 Identifier les messages (synchrones/asynchrones) entre les acteurs et les objets et entre les 
objets eux-memes. La chronologie des echanges doit etre respectee. 

4 Modeliser les fragments d'interactions si necessaire. 


Recommandations : 

1 Se limiter a la representation des principaux scenarios de chaque CU. 

2 Pour des messages ou des fragments d'interactions complexes, les expliciter par des notes. 

3 Utiliser des fragments d'interaction de type « ref » pour faciliter la lecture du DSE. 
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FICHE GUIDE -FG10 


Activite 3 : Analyse des cas d'utilisation 
Sous-activite 3.4 : 

Elaboration des diagrammes d'etat-transition 


Projet : 


Date : 


Objectif 


Definir d'une part les etats des objets significatifs du systeme etudie et 
d'autre part les actions associees aux transitions. 


Point de depart 


Cas d'utilisation decrits de maniere textuelle et concepts metiers identifies 
et definis. 


Point d'arrivee 


Les differents etats des objets et les transitions entre objets representes 
dans le DET. 


Demarche d'elaboration 


Pour chaque objet significatif du systeme etudie : 

1 Identifier les etats pertinents de I'objet a representee Considerer les etats elementaires mais 
aussi composites si necessaire. 

2 Definir les transitions entre les etats des objets avec eventuellement les gardes associees. 
Utiliser, le cas echeant, tous les operateurs disponibles (points de jonction, points de choix...). 

3 Definir les actions pour les transitions et les activites pour les objets. 

4 Representer I'etat initial et le ou les etats finaux. 


Recommandation : 

Utiliser uniquement les diagrammes d'etat pour des objets dont il est necessaire de 
comprendre le comportement dans tout le systeme (etats caracterisques). 
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FICHE GUIDE - FG1 1 


Activite 3 : Analyse des cas d'utilisation 
Sous-activite 3.5 : 

Elaboration des interfaces utilisateur 


Projet : 


Date : 


Objectif 


Modeliser les interfaces utilisateur de tous les cas d'utilisation pour donner 
une vue concrete de I'application aux utilisateurs. 


Point de depart 


Cas d'utilisation decrits de maniere textuelle et interactions entre acteurs et 
objets du systeme definies pour tous les cas d'utilisation. 


Point d'arrivee 


Interfaces utilisateur definies pour tous les cas d'utilisation. 


Demarche d'elaboration 


Pour chaque cas d'utilisation (CU) : 

1 Identifier toutes les « entrees » de I'lHM qui correspondent aux parametres des messages du 
DSE pour chaque CU. 

2 Representer les dispositifs d'« entrees » sous forme de composants IHM : 

- zone de saisie a I'ecran, 

- liste de choix, 

- boutons radios... 

3 Ajouter a I'lHM, les composants de validation (boutons). 

4 Representer les «sorties » de I'lHM qui correspondent aux resultats du message du DSE 
pour chaque CU. 


Recommandation : 

Realiser des interfaces utilisateur simples facilement modifiables compte tenu des frequents 
retours des utilisateurs a traiter. 
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FICHE GUIDE - FG12 


Activite 3 : Analyse des cas d'utilisation 
Sous-activite 3.6 : 

Elaboration des diagrammes de classe 


Projet : 


Date : 


Objectif 


Definir les classes pour chaque cas d'utilisation. 


Point de depart 


Interactions entre acteurs et objets du systeme definies pour tous les cas 
d'utilisation et concepts metiers definis dans la modelisation metier. 


Point d'arrivee 


Classes et associations definies pour chaque cas d'utilisation dans les DCL 
par cas d'utilisation. 


Demarche d'elaboration 


Pour chaque cas d'utilisation (CU) : 

1 Identifier les classes du CU en prenant comme base les objets definis dans le diagramme de 
sequence du CU et les concepts metiers. 

2 Preciser les attributs des classes a partir de ceux identifies dans le DSE (parametres des 
messages) et des « entrees » de NHM. 

3 Preciser les operations des classes a partir des messages du DSE et des actions et activites du 
DET. Un message « entrant » d'un objet correspond a une operation de la classe sollicitee. 

4 Determiner les relations entre les classes : 

- nom de I'association, 

- multiplicity, 

- type d'association (composition, agregation, association qualifiee, dependance, heritage...). 


Recommandation : 

S'assurer que le DCL de chaque CU reste lisible pour les acteurs metiers au moins au niveau 
du nom des classes et des principales relations. 
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Synthese de /'analyse 



FICHE GUIDE - FG13 


Activite 4 : Synthese de I'analyse 
Sous-activite 4.1 : 

Elaboration du diagramme de classe recapitulatif 


Projet : 


Date : 


Objectif 


Regrouper I'ensemble des classes dans un seul diagramme pour avoir une 
vision globale du systeme etudie. 


Point de depart 


Tous les diagrammes de classe des cas d'utilisation etudies. 


Point d'arrivee 


Regroupement des classes en un seul DCL. 


Demarche d'elaboration 


1 Recuperer I'ensemble des DCL de tous les CU. 

2 Mettre en commun, pour les memes classes, les attributs et operations de chaque classe 
definis dans les DCL par CU. Chaque classe doit etre decrite de maniere exhaustive. 

3 Mettre en commun toutes les associations entre les classes definies dans les DCL par CU. 

4 Determiner les relations entre differents DCL des CU. Mettre en place les nouvelles relations 
necessaires dans le DCL recapitulatif. 


Recommandation : 

S'assurer que le DCL recapitulatif reste lisible pour les acteurs metiers au moins au niveau du 
nom des classes et des principals relations. Etablir, le cas echeant, un DCL recapitulatif a deux 
niveaux de lecture. 
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FICHE GUIDE -FG14 


Activite 4 : Synthese de I'analyse 
Sous-activite 4.2 : 

Elaboration de la matrice de validation 


Projet : 


Date : 


Objectif 


Verifier la completude de I'analyse du systeme et etablir la tracabilite entre 
les CU metiers (activite exigences fonctionnelles) et les CU d'analyse 
(activite analyse des CU). 


Point de depart 


Les CU metiers et d'analyse. 


Point d'arrivee 


Completude de I'analyse du systeme verifiee et tracabilite entre les CU 
effectuee. 


Demarche d'elaboration 


1 Reprendre les CU metiers et d'analyse. 

2 Etablir une correspondence entre les CU metiers et les CU d'analyse via la matrice de 
validation. 

NB : des cas d'utilisation peuvent etre presents uniquement dans I'activite d'analyse des CU 
car ils repondent a une problematique specifique liee par exemple a la gestion des utilisateurs 
par un administrateur. 

3 Conclure sur la completude de I'activite d'analyse des CU en s'assurant que tous les CU 
metier ont ete repris dans I'activite d'analyse des CU. 


Recommandation : 

Mettre en evidence (gras) dans la matrice, les CU qui n'ont pas pour origine un CU metier. 
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Conception 



FICHE GUIDE - FG15 


Activite 5 : Conception 

Sous-activite 5.1 : 

Realisation des choix techniques 


Projet : 


Date : 


Objectif 


Choisir I'architecture technique cible et les technologies associees. 


Point de depart 


Etapes d'expression des besoins et d'analyse terminees 
(Activites 1,2,3, 4). 


Point d'arrivee 


Architecture technique et technologies associees choisies. 


Demarche d'elaboration 


1 Choix de I'architecture technique en fonction des contraintes techniques imposees lors de 
I'expression des besoins (ex. contraintes de performances), du contexte client (environnement 
technique cible) et de I'etat de I'art des technologies. 

2 Choix des technologies utilisees en fonction de I'architecture selectionnee et des contraintes 
techniques. 

NB : nous donnons, apres les fiches guides, une description complementaire sur cette sous- 
activite. 


Recommandation : 

Ne pas negliger la prise en compte des exigences techniques (contraintes de performances) 
qui peuvent avoir une influence forte sur le choix d'une architecture. 
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FICHE GUIDE - FG16 


Activite 5 : Conception 
Sous-activite 5.2 : 

Elaboration des diagrammes de sequence technique 


Projet : 


Date : 


Objectif 


Representer les interactions entre les acteurs et tous les objets du systeme 
(incluant les objets techniques) pour tous les cas d'utilisation en considerant 
les differents scenarios associes. Representer les objets en utilisant la 
classification d'lvar Jacobson* (Dialogue, Controleur, Entite). 

* voir le paragraphe sur les complements de la conception. 


Point de depart 


Architecture choisie, DSE et DCL de I'activite 3. 


Point d'arrivee 


Interactions entre les acteurs et tous les objets du systeme (incluant les 
objets techniques) definies pour tous les cas d'utilisation. 


Demarche d'elaboration 


Pour chaque cas d'utilisation (CU) et chaque scenario identifie : 

1 Reporter le ou les acteurs du DCU impliques dans le scenario. 

2 Representer les objets du systeme impliques dans le scenario en prenant comme base ceux 
identifies lors du DSE de I'activite 3 : 

- Objets « Dialogue ». 

- Objets « Controleur ». 

- Objets « Entite ». 

- Objets techniques (Collection, Date...) identifies uniquement lors de cette etape. 

3 Representer les messages (synchrones/asynchrones) entre les acteurs et les objets et entre 
les objets eux-memes. La chronologie des echanges doit etre respectee. 

4 Modeliser les fragments d'interaction si necessaire. 


Recommandations : 

1 Expliciter par des notes, les messages ou les fragments d'interactions complexes. 

2 Utiliser des fragments d'interaction pour faciliter la lecture du DSE. 
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FICHE GUIDE - FG1 7 



Activite 5 : Conception Projet : 

Sous-activite 5.3 : 

Elaboration des diagrammes de classe techniques Date : 



Objectif 



Definir toutes les classes (incluant les classes techniques) et associations 
pour tous les cas d'utilisation. Representer les classes en utilisant la 
classification d'lvar Jacobson (Dialogue, Controleur, Entite). 



Point de depart 



Interactions entre les acteurs et tous les objets du systeme (incluant les 
objets techniques) definies pour tous les cas d'utilisation et DCL de I'activite 
3. 



Point d'arrivee 



Toutes les classes (incluant les classes techniques) et associations definies 
pour tous les cas d'utilisation. 



Demarche d'elaboration 



Pour chaque cas d'utilisation (CU) : 

1 Representer les classes du CU en prenant comme base les objets definis dans le diagramme 
de sequence technique du CU et le DCL de I'activite 3. Repartir les classes en plusieurs 
categories : 

- Classes « Dialogue ». 

- Classes « Controleur ». 

- Classes « Entite » (classes du DCL activite 3). 

- Classes techniques (Collection, Date...) identifies uniquement lors de cette etape. 

2 Preciser les attributs des classes et leurs caracteristiques (visibility, type, valeur initiate. . .) a 
partir de ceux identifies dans le DSE (parametres des messages). 

3 Preciser les operations des classes et leurs caracteristiques (parametres avec type, type de 
resultat) a partir des messages du DSE. 

4 Determiner les relations entre les classes : 

- Norn de I'association. 

- Multiplicity. 

- Type d'association (composition, agregation, association qualifiee, dependance, heritage...). 

- Contraintes (ordonnees, non ordonnees...). 



Recommandation : 

Veiller a regrouper dans la modelisation les classes « dialogue », « controleur », et « entite » 
pour une meilleure lecture du diagramme. 
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FICHE GUIDE - FG18 


Activite 5 : Conception 
Sous-activite 5.4 : 

Elaboration du diagramme de paquetage 


Projet : 


Date : 


Objectif 


Regrouper l'ensemble des classes en paquetage pour avoir une vision 
globale et structuree du systeme etudie. 


Point de depart 


Tous les diagrammes de classe par cas d'utilisation. 


Point d'arrivee 


Regroupement de l'ensemble des classes dans un seul diagramme de 
paquetage. 


Demarche d'elaboration 


1 Regrouper I'ensemble des classes par ensemble homogene. Chaque ensemble correspond 
a un paquetage (ex . Gestion Mail). L'ensemble peut correspondre a un decoupage technique 
(archictecture en couches) ou fonctionnel. 

2 Determiner les dependances entre les paquetages : 

- « import » 

- « access » 


Recommandations : 

1 Veiller a respecter deux principes pour le regroupement des classes en paquetage : 

- Coherence interne : constitution d'un ensemble homogene fonctionnel/technique. 

- Faible couplage externe. 

2 Ne pas representer sur le DPA les dependances « import » par transitivite. 
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4.5.3 Complements sur la conception 

Deux points abordes dans les fiches guides sur la conception meritent un 
approfondissement : 

• En premier lieu, la sous-activite « realisation des choix techniques » effectuee 
au debut de Pactivite de conception pour determiner Parchitecture technique 
et les technologies associees. Cette sous-activite ne fait pas partie directement 
du champ d'UML et est fortement liee a Involution des technologies. 

• En second lieu, la classification d'lvar Jacobson qui permet de repartir les clas- 
ses pour les diagrammes de Pactivite de conception dans trois categories 
(« dialogue », « controleur », et « entite »). 

Realisation de choix techniques 

Les choix techniques portent sur une architecture technique et des technologies 
associees. Pour mieux comprendre les choix techniques a realiser, nous allons 
prendre Pexemple du domaine du web. Pour cela, une presentation des principales 
architectures web est detaillee. 

L'architecture web la plus utilisee aujourd'hui est Parchitecture multitiers (ri- 
ders). Elle vient s'opposer aux architectures plus anciennes comme Parchitecture 
mainframe et client/serveur par la repartition des couches applicatives. 

La structuration des applications en couches permet : 

• de maitriser la complexite des applications (developpement, echanges entre 
les applications et interactions entre objets) ; 

• d'ameliorer le decouplage de Papplication ; 

• de diminuer les temps de developpement, en factorisant certaines briques 
applicatives ; 

• de favoriser la communication : 

- a Pinterieur d'une application, en structurant les echanges entre les diffe- 
rentes couches ; 

- entre les applications, en precisant les principes de communication lies aux 
couches de diverses applications. 

Deux principales architectures n-tiers sont utilisees aujourd'hui. 

[.'architecture classique a trois couches 



Presentation 



Domaine 



Persistance 





Q MO 



►O — w 



►o- 1 



Figure 4.7 — 



Architecture classique a trois couches 
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Les trois couches suivantes sont presentes : 

• Couche presentation - Cette couche contient l'interface homme-machine. 
C'est la couche de presentation des donnees a l'utilisateur. Elle contient 
uniquement les pages de mise en forme des donnees en vue de leur affichage. 

• Couche domaine - Cette couche contient les objets du domaine (facture, bon 
de commande, client...). Ces objets encapsulent toutes les regies metier et 
appliquent la logique fonctionnelle de l'application. 

• Couche persistance - Cette couche contient les usines d'objets metier, c'est- 
a-dire les classes chargees de creer des objets metier de maniere totalement 
transparente, independamment de leur mode de stockage (DAO, objet de 
mapping...). 

L'architecture orientee service (SO A) 

Presentation Coordination Services Domaine Persistance 




Figure 4.8 — Architecture orientee service (SOA) 

Dans cette architecture, deux nouvelles couches apparaissent. 

• Couche coordination - Cette couche gere l'organisation des donnees a affi- 
cher. C'est un controleur qui gere l'enchainement des pages a afficher (Page 
Flow) en fonction des differentes demandes formulees par l'utilisateur. 

• Couche services - Cette couche gere l'aspect SOA de l'application. Chaque 
demande de l'utilisateur correspond a un service appele par cette couche, qui 
appelle les couches inferieures, et renvoie le resultat de son traitement a la 
couche superieure. C'est egalement la couche service qui gere les transactions. 

Cette architecture presents les specificites suivantes par rapport aux architectu- 
res classiques : 

• La couche coordination ne manipule plus directement les objets metiers, mais 
passe par des appels de services. 

• Les objets metiers se trouvent dans des bibliotheques de classe directement 
chargees dans le meme processus que les services ; le cout des appels aux objets 
metiers est alors tres faible. 

• Les services agissent comme des « boites noires » faisant abstraction de la 
complexite du modele objet. Ces services presentent un ensemble de fonc- 
tionnalites restreintes et permettent de reduire les echanges entre les couches. 
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Concernant les technologies utilisees pour ces architectures, deux solutions 
dominent le marche : J2EE proposee par Sun et .NET proposee par Microsoft. Ces 
solutions ne seront pas detaillees dans cet ouvrage. 

Classification d'lvar Jacobson 

La classification d'lvar Jacobson permet d'identifier les classes « dialogue », 
« controleur » et « entite » dans un systeme : 

• Les classes « dialogue » - Elles servent a modeliser les interactions entre le 
systeme et ses utilisateurs. Les parametres saisis par les utilisateurs peuvent 
etre represented sous forme d'attributs de classe. Les actions proposees a l'utili- 
sateur sur chaque page sont representees sous forme d'operations nominees par 
un verbe. 

Elles ne peuvent etre qu'associees uniquement aux classes « controleur » ou a 
d'autres classes « dialogue ». 

• Les classes « controleur » - Elles sont utilisees pour representer la coordina- 
tion, l'enchainement et le controle d'autres objets. Generalement, une seule 
classe « controleur » par cas d'utilisation. Mais sur le diagramme on peut 
montrer qu'un controleur appelle le controleur d'un autre cas d'utilisation. II 
est possible de modeliser les operations effectuees par le controleur et declen- 
chees par des actions au niveau des dialogues ou periodiquement. 

Elles peuvent etre associees a tous les types de classe. 

• Les classes « entite » - Elles servent a modeliser des informations durables et 
souvent persistantes. Les classes « entite » sont issues des concepts metier du 
modele de domaine ou bien sont nouvellement creees dans le diagramme si ce 
sont des entites purement « applicatives » ou techniques. 

Les classes « entite » ne peuvent etre qu'associees uniquement aux classes 
« controleur » ou a d'autres classes « entite ». 



_5_ 

Etude de cas n° 1 
Analyse 



5.1 ENONCE DU CAS ALLOC 

Chaque annee, au troisieme trimestre, les directeurs de laboratoire de recherche 
expriment leurs demandes de moyens pour l'annee a venir aupres de leur direction 
scientifique. Une demande porte sur les moyens humains et sur les moyens finan- 
ciers. 

Chaque demande est etudiee par la direction scientifique a laquelle le laboratoire 
est rattache. 

Les propositions d'allocation de moyens des directions scientifiques font ensuite 
l'objet d'une consolidation generale par un coordonnateur afin de soumettre ces pro- 
positions a l'arbitrage de la direction generale. Cet ultime arbitrage permet d'aboutir 
a une decision definitive d'allocation de moyens aux laboratoires. 

Chaque directeur scientifique notifie a ses laboratoires les decisions d'allocation 
de moyens pour l'annee n + 1. 



Dans le cadre de cette premiere etude cas, il est systematiquement indique, pour chaque 
diagramme ou activite a produire, le numero de la fiche guide qui apporte un support 
methodologique a la mise en oeuvre de la demarche d'UML (UP7) preconisee dans cet 
ouvrage. 
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5.2 MODELISATION METIER 



5.2.1 Elaboration du schema de contexte du domaine d'etude (FG1) 

Conformement a notre demarche UP7, nous recommandons d'etablir en premier un 
schema de contexte permettant de situer le domaine d'etude par rapport aux autres 
processus de l'entreprise. 

Ainsi, nous observons (fig. 5.1) que le domaine d'etude est en etroite relation 
avec deux processus importants traitant respectivement les ressources humaines et 
les moyens financiers. 



Processus ressources humaines 




Processus financiers 



Decision d'attribution 



Directeur d'unite 

Figure 5.1 - Schema de contexte du domaine d'etude 



5.2.2 Elaboration du diagramme d'activite (FG2) 

Quatre acteurs principaux interviennent dans les processus d'allocation des moyens 
(fig. 5.2) : 

• Le directeur de laboratoire (DU) - C'est lui qui exprime la demande de 
moyens a sa direction scientifique. 

• Le directeur scientifique (DS) - II instruit la demande et elabore des propo- 
sitions d'allocation de moyens. 

• Le coordonnateur (CO) - II saisit les cadrages des moyens a respecter par les 
DS et consolide les propositions faites par les DS avant de les soumettre a 
l'arbitrage du DG. II saisit ensuite les eventuels ajustements des cadrages apres 
les arbitrages. 

• La direction generale (DG) - Elle arbitre definitivement les propositions 
d'allocation des moyens aux laboratoires apres discussion avec les directeurs 
scientifiques. 
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DU 



(Exprimer A 
la demande J 



rDemande exprimeel 



^ Recevoir attribution^ 



DS 



^ Instruire ^ 



TDemande instruitel 



CO 



\ 

Organiser instruction 



TCadraqe saisil 



[Attribution proposeel 



^onsolider propositi^ 



^1 



TCadraqe aiustel 



^ Allouer moyens^, 



[Attribution alloueel 



DG 



Cadrage 



[Attribution consolideel 



^ Arbitrer ^ 



[Attribution arbitreel 



Figure 5.2 — Diagramme d'activite du domaine 



5.2.3 Elaboration du diagramme de classe metier (FG3) 

Les concepts metier pris en compte dans le diagramme de classe metier (fig. 5.3) sont : 

• Unite - Laboratoire de recherche exprimant une demande annuelle de 
moyens. 

• Demande de l'unite - Demande annuelle de moyens exprimee par le direc- 
teur de l'unite. 

• Attribution des moyens - Attribution de moyens proposee par le DS et 
ensuite arbitree par le DG. 

• Cadrage DS - Enveloppe fixee par le DG pour chaque DS et type de moyens. 

• DS - Departement scientifique de rattachement de l'unite. 
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• Histo-demandes - Historique de toutes les demandes en ressources humaines 
ou en ressources financieres exprimees par l'unite. 

• Histo-attributions - Historique des attributions en ressources humaines ou 
en ressources financieres faites a l'unite. 



numAttrib 
dateAttrib 




Attributions 



allouer 



Unite 



-code unite 
-intitule unite 
-nom directeur 
-adresse rue 
-adresse ville 
-adresse code postal 



Cadrage-DS 



-DStypeMoyenC 
-cadrageA 
-date arbitrage 




TypeMoyen 



■typemoyen 
-intituleTypemoyen 



rattacher 



DS 



-codeDS 
-intituleDS 



allouer-histoRH 

r 



Histo-attribution-RH 



Demande-RH 



-gradeD 
-nombreD 
-justificationD-RF 



numAttribHA-RH 
allouer-histoRFl -dateAttribHA-RH 
-gradeHA-RH 
-nombreHA-RH 



InterfaceUtilisateur 



■prenom 
■id 




■typeMoyensD 
■montantD 
■justificationD-RF 



Histo-demande-RF 



-numDemandeHD-RF 
-dateDemandeHD-RF 
-typemoyensHD-RF 
-montanHD-RF 



Histo-attribution-RF 



numAttribHA-RF 
dateAttribHA-RF 
typeMoyensHA-RF 
montantHA-RF 



Figure 5.3 — Le diagramme de classe metier 

5.2.4 Extrait des documents de cadrage 

Des exemples de cadrage sont donnes ci-apres. 



Cadrage des moyens a allouer pour I'annee n 


Departements 
scientifiques 


Ressources humaines (RH) 


Ressources financieres (RR en k€ 




Chercheurs 


Ingenieurs 


Budget 

de fonctionnement 


Budget 
d'equipement 


Chimie 


12 


15 


21 000 


4 000 


Physique 


8 


7 


12 000 


3 000 


Sciences de la vie 


22 


25 


63 000 


1 1 000 
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Demande de moyens des unites pour I'annee n 


Departements 
Chimie 


Ressources humaines (RH) 


Ressources financieres (RF) en k€ 




Chercheurs 


Ingenieurs 


Budget 

de fonctionnement 


Budget 
d'equipement 


Unite 1 


2 


3 


1 000 


500 


Unite 2 


1 


2 


800 


200 


Unite 3 


1 


2 


900 


700 



En resume, les quatre types de moyen considered dans cette etude de cas sont : 



• RH-chercheurs, 

• RH-ingenieurs, 

• RF-budget, 

• RF-equipement. 



5.3 EXIGENCES FONCTIONNELLES 

5.3.1 Elaboration du diagi amine des cas d'utilisation systeme (FG4) 

Representation du DCU 

A partir du diagramme d'activite et de la connaissance des besoins des acteurs, nous 
elaborons une vision generate des cas d'utilisation du futur systeme en produisant le 
DCU systeme (fig. 5.4). 

Description generate des cas d'utilisation 

• Cas d'utilisation 0- « Saisir demande » - II s'agit de la saisie des donnees de 
la demande de moyens par les directeurs d'unites (DU). Cette saisie ne fait pas 
partie du champ d'etude du systeme car elle est prise en charge par un systeme 
d'information existant. II convient seulement de prevoir une interface 
permettant de recuperer les informations apres saisie. 

• Cas d'utilisation 1- « Gerer les cadrages » - Chaque annee des cadrages sont 
fixes par le DC pour chaque DS et chaque type de moyens. Ces cadrages sont 
saisis par le coordonnateur (CO). Apres arbitrage par le DC, les cadrages 
peuvent eventuellement etre ajustes. 

• Cas d'utilisation 2- « Editer les fiches de demande » - Apres integration des 
donnees saisies dans le systeme, celles-ci doivent pouvoir etre consultees par 
les personnes qui sont chargees de leur exploitation. C'est Pedition des fiches 
de demande qui repondra a ce besoin. 
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Figure 5.4 — Le diagramme des cas d'utilisation systeme 



• Cas d'utilisation 3- « Proposer les attributions de moyens » - Apres etude 
des demandes et compte tenu des moyens disponibles, les DS precedent a 
l'attribution des moyens humains et financiers unite par unite. Ces attribu- 
tions sont en fait a considerer comme des propositions tant que l'arbitrage de 
la direction generate n'a pas ete rendu. 

• Cas d'utilisation 4- « Gerer les moyens proposes » - La gestion des moyens 
consiste en la consolidation generale des moyens a attribuer et a la production 
de tableaux de bord de suivi. 

• Cas d'utilisation 5- « Enregistrer l'arbitrage DG des propositions » - Un 
certain nombre de moyens ne peuvent etre attribues que si le directeur general 
a donne son accord. Ce dernier doit etre enregistre dans le systeme par le 
coordonnateur. 

• Cas d'utilisation 6- « Notifier les moyens arbitres » - Les moyens arbitres 
doivent etre communiques aux unites a l'aide de courriers produits automati- 
quement. 
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5.3.2 Elaboration du diagramme de sequence systeme (FG5) 

Au stade de la description du niveau metier, il est possible de donner une premiere 
representation des diagrammes de sequence (DSE) en considerant les interactions 
entre les acteurs et le systeme pris dans son ensemble. Ainsi, nous etablissons : 

• Le DSE du cas d'utilisation 1 « Gerer les cadrages » (fig. 5.5). 

• Le DSE du cas d'utilisation 2 « Editer les fiches de demande » (fig. 5.6). 

• Le DSE du cas d'utilisation 3 « Proposer les attributions de moyens » 
(fig. 5.7). 

• Le DSE du cas d'utilisation 4 « Gerer les moyens proposes » (fig. 5.8). 

• Le DSE du cas d'utilisation 5 « Enregistrer l'arbitrage DG des propositions » 
(fig. 5.9). 

• Le DSE du cas d'utilisation 6 « Notifier les moyens arbitres » (fig. 5.10). 



CO 



<<systeme>> 
: ALLOC 



demanderChoisirTypemoyen( ) 



demanderSaisirCadrage(DS, typemoyen) 

ecran cadrage 
saisirCadrage(nombre) 



afficherCadrage( ) 



cadrage 
modifierCadrage(nombre) 



T] 



cadrage modifie 



Figure 5.5 — DSE du cas d'utilisation 
1- « Gerer les cadrages » 
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<<systeme>> 
: ALLOC 



: PS 



demanderFiches(DS) j 






<■ ; ; 

hste unites 

choisirUnites(listeUnites) 






< 

fiches de demande 



Figure 5.6 — DSE du cas d'utilisation 
2- « Editer les fiches de demande » 




<<systeme>> 
: ALLOC 



demanderChoisirTypemoyen( ) 



DS 



idemandeProposerAttribution(DS, typemoyen) 



"IKte'ijnites" 



'OOP our toutes les unites a traiter 

choisirUnite(codeUnite) 



ecran de saisie d'une attribution 
saisirAttribution(nombre) 



resultat du controle des donnees saisies 
validerAttribution(codevalid) 



attribution enregistree 



Figure 5.7 — DSE du cas d'utilisation 
3- « Proposer les attributions de moyens » 



5.3 Exigences fonctionnelles 



157 



o 

X 

: CO 



<<systeme>> 
: ALLOC 



demanderChoisirTypemoyen( ) 



demandeConsoliderPropositions(type[TO 



oyjn 



consoliderPropRubriques(listeRubriq ^ eS) 



fichier de consolidation 



Figure 5.8 — DSE du cas d'utilisation 
4- « Gerer les moyens proposes » 







<<systeme>> 
: ALLOC 


CO 


demanderChoisirTypemoyen( ) 








demanderSaisirArbitrage(DS, typemoyen) 








i<... 




► 








ecran arbitrage 
saisirArbitrage(dateArbitrage) 


► 






!<■■■ 












confirmer arbitrage saisi 
validerArbitrage(codeV) 















Figure 5.9 — DSE du cas d'utilisation 
5- « Enregistrer I'arbitrage DG des propositions » 
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Figure 5.10 — DSE du cas d'utilisation 
6- « Notifier les moyens arbitres » 



5.3.3 Elaboration du schema de navigation generale (FG6) 

L'enchainement global des ecrans peut etre donne a ce stade (fig. 5.11). 



Allocation des moyens 



Gestion 
des cadrages 



Edition 

des fiches de demandes 



Proposition 
d'attribution 



Gestion 

des moyens attribues 



Arbitrage 

des propositions 



Notification 

des moyens attribues 



Figure 5.11 — 



Schema de navigation generale 



5.4 Analyse des cas d'utilisation 
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5.4 ANALYSE DES CAS D'UTILISATION 

5.4.1 Elaboration du diagramme des cas d'utilisation (FG7) 

A partir du premier DCU elabore dans la partie « exigences fonctionnelles », il est 
possible d'affiner maintenant Panalyse des differents cas. Cette analyse conduit a 
ajouter deux cas d'utilisation. 

Choisir type de moyens 

Ce cas permet de decrire une seule fois les actions liees au choix d'un type de moyens 
et de proposer aux autres cas d'y recourir avec la fonction « include » si besoin. 

Suivre I'avancement des attributions 

Ce cas est en fait une extension du cas n° 4 avec Putilisation de la fonction 
« extend ». II permet au coordonnateur de disposer, quand cela est utile, des 
tableaux de suivi des attributions. Le diagramme complet des cas d'utilisation est 
donne a la figure 5.12. 




^^T^Gerer les cadrages 



<<include>> 



Figure 5.12 — Diagramme des cas d'utilisation 



5.4.2 Description des cas d'utilisation (FG8, FG9, FG1 1, FG12) 

Pour la suite de Petude de cas, nous allons produire Panalyse des huit cas d'utilisation 

• Cas 1- « Gerer les cadrages » 

• Cas 2- « Editer les fiches de demande » 
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• Cas 3- « Proposer les attributions de moyens » 

• Cas 4- « Gerer les moyens proposes » 

• Cas 5- « Enregistrer l'arbitrage DC des propositions » 

• Cas 6- « Notifier les moyens arbitres » 

• Cas 7- « Choisir type de moyens » 

• Cas 8- « Suivre l'avancement des attributions » 

Pour chaque cas d'utilisation, les sous-activites suivantes de Tactivite « Analyse 
des cas d'utilisation » sont realisees : 

• Description (textuelle) du cas d'utilisation (FG8) 

• Elaboration du diagramme de sequence (FG9) 

• Elaboration de l'interface utilisateur (FG1 1 ) 

• Elaboration du diagramme de classe (FG12) 

Cas d'utilisation 1- « Gerer les cadrages» 

Description textuelle du cas d'utilisation 

• Objectif - Permettre au coordonnateur de saisir, de consulter ou de modifier 
des donnees de cadrage pour un type de moyens. 

• Acteur concerne - Coordonnateur. 

• Pre condition - Aucune. 

• Scenario nominal : saisie d'un nouveau cadrage 

1 Le coordonnateur choisit un type de moyen pour un DS donne. 

2 Le coordonnateur renseigne les donnees de cadrage. 

3 Le systeme verifie la presence des donnees obligatoires. 

4 Le systeme affiche les donnees a enregistrer pour validation. 

5 Le systeme enregistre la saisie validee. 

• Scenarios alternatifs 

2-a Modification des donnees de cadrage : 

- Le systeme affiche le formulaire de saisie des donnees de cadrage enregis- 
trees. 

- Le coordonnateur modifie les donnees. 

- Le cas d'utilisation reprend a Taction 3 du scenario nominal. 
2-b Consultation des donnees de cadrage : 

- Le systeme affiche les donnees de cadrage deja enregistrees. 

- Fin du cas d'utilisation. 

4-a Erreurs detectees dans la saisie : 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detec- 
tees. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend au point 3 du scenario nominal. 



5.4 Analyse des cas d'utilisation 
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Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.13), Pelaboration de l'interface utilisateur (tab. 5.1) et Pelabora- 
tion du diagramme de classe (fig. 5. 14)- 



Dans le DSE, les cas d'erreurs ainsi que la recherche des intitules DS et type de 
moyen n'ont pas ete representes. 



: CO 



InterfaceUtilisateur 



demanderChoisirTypemoyen( ) 



demanderSaisirCadrage(DS, typemoyen) 



ecran cadrage 
saisirCadrage(nombre) 



confirmerSaisie(accord) 



afficherCadrage(DS, typemoyen) 



cadrage 
modifierCadrage(nombre) 



cadrage modifie 



Cadraqe-DS 



demanderSaisirCadrage(DS, typemoy e n )i 



ecran cadrage 
saisirCadrage (nombre) 



u 

i 



validerSaisie(typemoyen, accord) 



afficherCadrage(DS, typemoyen) 



cadrage 

modifierCadrage(DS, typemoyen, norr^brd) 



cadrage modifie 



Dmbra) 



Figure 5.13 — Diagramme de sequence du cas d'utilisation 
1 - « Gerer les cadrages » 



Tableau 5.1 — Donnees de l'interface utilisateur du cas d'utilisation 1 



Donnees affichees 


Donnees saisies 


- Code et intitule DS 


- DS et typemoyen 


- Code et intitule du type de moyen a traiter 


- Nombre correspondant au cadrage du type 
de moyen selectionne 


- Nombre correspondant au cadrage du type 
de moyen selectionne 


- Validation 
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Interfacelltilisateur 



■nom 

-prenom 

■id 



+saisirCadraae(") 

+afficherCadrage() 

+ mod if ierCadrageQ 

+demanderChoisirTypemoyen() 

+confirmerSaisie() 

+demanderSaisirCadrage() 



Cadrage-DS 



-DStypeMoyenC 

-cadrageA 

-date 



+afficherCadrage() 

+saisirCadrage() 

+validerSaisie() 

+modifierCadrage() 

+demanderSaisirCadrage() 




DS 



-codeDS 
-intituleDS 



TypeMoyen 



-typemoyen 
-intituleTypemoyen 



Figure 5.14 — Diagramme de classe du cas d'utilisation 1 

Cas d'utilisation 2- « Editer les fiches de demande » 

Description textuelle du cas d'utilisation 

• Objectif - Permettre aux departements scientifiques de produire les fiches de 
demande de moyens. 

Une fiche de demande (FD) presente un ensemble d'information concernant 
une unite donnee. Elle regroupe l'ensemble de ses demandes pour Pannee 
N + 1. Un rappel de sa situation a Pannee N est aussi indique (en demande de 
moyens et moyens attribues). 

• Acteur concerne - DS. 

• Pre condition - Toutes les unites du departement ont exprime leur demande. 

• Scenario nominal 

- Le DS demande Pedition de fiches. 

- Le systeme affiche les unites du DS. 

- Le DS selectionne les unites concernees. 

- Le systeme construit et affiche le contenu de la fiche pour les unites selec- 
tionnees. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de Panalyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.15), Pelaboration de Pinterface utilisateur (tab. 5.2) et Pelabora- 
tion du diagramme de classe (fig. 5.16). 

Cas d'utilisation 3- « Proposer les attributions de moyens » 
Description textuelle du cas d'utilisation 

• Objectif - Permettre au DS de saisir ou de consulter des propositions d'attri- 
butions. 

• Acteur concerne - DS. 

• Pre condition - Aucune. 
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Tableau 5.2 — 



Chapitre 5. Etude de cas n° I Analyse 

Donnees de I'interface utilisateur du cas d'utilisation 2 



Donnees affichees 


Donnees saisies 


- Code et intitule DS 


-DS 


- Liste des unites du DS 


- Codes unites choisies 


Pour chaque unite choisie : 

- Nom du directeur 

- Adresse 

- Numero de demande 

- Date de la demande 

- Demandes RH et RF 

- Historique demandes RH et RF 

- Historique attributions RH et RF 



DS 

codeDS 
intituleDS 



listerUnites() 
+extraireFiche() 



Demande 



numDemande 
dateDemande 



+extraireDemandeF() 



emettre 



Interfacelltilisateur 



-nom 
-prenom 



+demanderFiches() 
+choisirUnites() 



rattacher 



allouer-histoRH 



Unite 



-code unite 
-intitule unite 
-nom directeur 
-adresse rue 
-adresse ville 
-adresse code posttl 



HlisterUnites() 



Histo-Attribution-RH 



-numAttribHA-RH 
-dateAttribHA-RH 
-gradeHA-RH 
-nombreHA-RH 



-extraireHistoA-RH() 



allouer-histoRF 



demander-histoRH 



Histo-Demande-RH 

-numDemandeHD-RH 

-dateDemandeHD-RH 

-gradeHD-RH 

-nombreHD-RH 

-justificationHD-RH 



+extraireHistoD-RH() 



demander-histoRF 



Histo-Attribution-RF 



-numAttribHA-RF 
-dateAttribHA-RF 
-typeMoyensHA-RF 
-montantHA-RF 



+extraireHistoA-RF() 



Histo-Demande-RF 



-numDemandeHD-RF 

-dateDemandeHD-RF 

-typemoyensHD-RF 

-montantHD-RF 

-justificationHD-RF 



+extraireHistoD-RF() 
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Figure 5.16 — Diagramme de classe du cas d'utilisation 2 



• Scenario nominal 

1 Le DS choisit le type de moyen a traiter. 

2 Le systeme affiche la liste des unites du DS. 

3 Le DS choisit l'unite pour laquelle il veut faire une proposition d'attribution. 

4 Le systeme affiche le formulaire de saisie des propositions d'attribution pre 
rempli avec les demandes du type de moyen selectionne effectuees par l'unite. 

5 Le DS renseigne les donnees de la proposition d'attribution. 

6 Le systeme verifie la presence des donnees obligatoires. 

7 Le systeme enregistre la saisie et affiche les attributions mises a jour. 
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• Scenarios alternatif s 

4-a Saisie d'une proposition d'attribution sans demande prealable 

- Le systeme affiche le formulaire de saisie des propositions d'attribution vierge. 

- Le cas d'utilisation reprend a Taction 5 du scenario nominal. 
4-b Modification d'une proposition d'attribution saisie 

- Le systeme affiche le formulaire de saisie des propositions d'attribution 
avec les demandes et les propositions d'attribution de l'unite pre-remplies. 

- Le cas d'utilisation reprend a Taction 5 du scenario nominal. 
4-c Consultation des propositions d'attribution 

- Le systeme affiche les propositions d'attribution de Tunite selectionnee 
avec les demandes de moyens associees. 

- Fin du cas. 

7 -a Erreurs detectees dans la saisie 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detectees. 

- L'instructeur corrige les erreurs. 

- Le cas d'utilisation reprend au point 6 du scenario nominal. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de Tanalyse du cas d'utilisation se poursuit par Telaboration du diagramme 
de sequence (fig. 5.17), Telaboration de Tinterface utilisateur (tab. 5.3) et Telabora- 
tion du diagramme de classe (fig. 5.18). 



: InterfaceUtilisateur 




: DS 









: Demande 



: Attributions 



: DS demanderChoisirTypemoyenQ 



demahderProposerAttribution(DS, typemoyen) listerUnites(DS) extra ireUnit|s() 



liste unites 
choisirL)neunite(codeUnite) 



loop Toutes les unites du DS ^~ 



finite extraite _ 



liste unites 

afficherSaisieAttrjbution(codellnite, typemoyen) 

extraireDemandePfcqdeUnite, typemoyen) 



ecran de saisie d'une attribution 
saisir Attribution (typemoyen, codellnite, nom bre) 



Tr 



Pfcrjde 
11 



coptrolerAttributionftypemoyen, codeUnite, 



nombre) 



resyltat du controle des donnees saisiesL 
validerAttribution(codevalid) 



attribution enregistree 



r^sultat controle 
validerAttribution(codevalid) 



attribution enregistree 



Figure 5.17 — Diagramme de sequence du cas d'utilisation 3 



Dans le DSE, seul le scenario nominal est represente pour le traitement d'une uni- 
te. La recherche de Tintitule DS et type de moyen n'a pas ete traitee. 
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Tableau 5.3 — 



Chapitre 5. Etude de cas n° I Analyse 

Donnees de I'interface utilisateur du cas d'utilisation 3 



Donnees affichees 


Donnees saisies 


- Code et intitule DS 


- DS et typemoyen 


- Code et intitule du type de moyen a traiter 


- Code de I'unite a traiter 


- Demande RH 

- Demande RF 


- Nombre propose pour le type de moyens 
traite 


- Attribution proposee RH 

- Attribution proposee RF 


- Validation de la saisie 



InterfaceUtilisateur 



■nom 

■prenom 

■id 



+saisirAttribution() 

+validerAttribution() 

+demanderChoisirTypemoyen() 

+demandeProposerAttribution() 

+choisirUneunite() 



correspondre 



0..1 



Demande 



-numDemande 
■dateDemande 



+extraireDemandeP() 



Attributions 



-numAttrib 
-dateAttrib 



+controlerAttribution() 
+validerAttribution() 



rattacher> 



DS 



•codeDS 
•intituleDS 



+listerllnites() 



Unite 



■code unite 
■intitule 
■noni directeur 
■adresse rue 
■adresse ville 
■adresse code postal 



+afficherSaisieAttribution() 
+listerUnites() 



TypeMoyen 



-typemoyen 
-intituleTypemoyen 



Figure 5.18 — Diagramme de classe du cas d'utilisation 3 



Cas d'utilisation 4- « Gerer les moyens proposes » 

Description textuelle du cas d'utilisation 

• Objectif - Permettre au coordonnateur d'exporter le fichier contenant les 
elements relatifs aux demandes et aux propositions d'attribution de moyens 
pour l'elaboration des documents presentes au DG en vue de leur arbitrage. 

• Acteur concerne - Coordonnateur. 

• Pre condition - Aucune. 

• Scenario nominal 

1 Le coordonnateur choisit le type de moyen a traiter. 

2 Le coordonnateur demande a extraire le fichier pour la consolidation des 
propositions d'attribution. 
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3 Le systeme liste les differences rubriques des propositions d'attribution dans 
le fichier 

4 Le coordonnateur selectionne les rubriques souhaitees. 

5 Le systeme genere le fichier de consolidation des propositions d'attribution 
pour toutes les unites. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par l'elaboration du diagramme 
de sequence (fig. 5.19), l'elaboration de l'interface utilisateur (tab. 5.4) et l'elabora- 
tion du diagramme de classe (fig. 5.20). 



InterfaceUtilisateur 




demand erListeRjjbriques(typemciyen) 
liste rubriquel'a choisir *Q 



L'obtention de la liste des rubriques disponibles 
pour unite et attributions n'est pas representee 



Pour tous les DS 



extr; i e ■loyensPftyr. 3moy gn 



noyens propc 5es d'unpS 



loo ~ \ Poijr toutes les unites d'un DS 

" listeRubriques): 

extra ireDemajideG(typemoyen 



extraireAt ributio iC (typemoyens . lis teRubriques) *[j 



listeRubriques) 
extra i re Demand $G(typemoyen, lisjeRubriques) 



extra ireAttributionG(typemoyen, listeRubriques) 

i 



fichier de consolidation de tous les D£ 



Figure 5.19 — Diagramme de sequence du cas d'utilisation 4 



Tableau 5.4 - 



Donnees de l'interface utilisateur du cas d'utilisation 4 



Donnees affichees 


Donnees saisies 


- Code et intitule type moyen 


- Type moyen 


- Liste des rubriques du fichier 


- Liste des rubriques choisies 


- Nombre correspondant aux demandes et aux 
moyens proposes 
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InterfaceUtilisateur 



■nom 

■prenom 

■id 



+consoliderPropRubriques() 

4demanderConsoliderProposition() 

+demanderChoisirTypemoyen() 



TypeMoyen 



-typemoyen 
-intituleTypemoyen 



correspond re 



0..* 



Attributions 



-numAttrib 
-dateAttrib 



+ ex tra ireAttributbnG( ) 



0..1 



Demande 



-numDemande 
-dateDemande 



+extraireDemandeG() 



emettre 



DS 



■codeDS 
-intituleDS 



+extraireMoyensP() 



albuer 



Unite 



-code unite 
-intitule unite 
-nom directeur 
-adresse rue 
-adresse ville 
-adresse code postal 



+extraireDemandeG() 

+demanderListeRubriques() 

+exraireAttributbnG() 



Figure 5.20 — Diagramme de classe du cas d'utilisation 4 



Cas d'utilisation 5- « Enregistrer I'arbitrage DG des propositions » 
Description textuelle du cas d'utilisation 

• Objectif - Permettre au coordonnateur de saisir I'arbitrage de la direction. 

• Acteur concerne - Coordonnateur. 

• Pre condition - RAS 

• Scenario nominal 

1 Le coordonnateur choisit un type de moyen pour un DS donne. 

2 Le systeme affiche le formulaire de saisie des etats d'arbitrage des types de 
moyen pre rempli. 

3 Le coordonnateur renseigne la date d'arbitrage. 

4 Le systeme verifie la conformite des donnees saisies. 

5 Le systeme demande la validation des donnees saisies. 

6 Le systeme enregistre la saisie, apres validation, et affiche le resultat de la 
mise a jour. 

• Scenarios alternatifs 

5 -a Erreurs detectees dans la saisie : 

- Le systeme reaffiche le formulaire de saisie en indiquant les erreurs detectees. 

- Le coordonnateur corrige les erreurs. 

- Le cas d'utilisation reprend au point 4 du scenario nominal. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.21), l'elaboration de l'interface utilisateur (tab. 5.5) et Pelabora- 
tion du diagramme de classe (fig. 5.22). 
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CO 



: InterfaceUtilisateur 




: Cadraqe-DS 









demanderChoisirTypemoyenQ 



demanderSaisirArbitrage(DS, typemoyen) U afficherArbitrage(DS, Wrje moyen) 



ecran arbitrage 
saisirArbitrage(dateArbitrage) 



ecran arbitrage 



=0 



confirmer arbitrage saisi 
validerArbitrage(codeV) 



modifierArbitrage(dateAj-bitrage) 



arbitrage modifie 
validerArbitrage(code\ g 



Figure 5.21 — Diagramme de sequence du cas d'utilisation 5 



Seul le scenario nominal est represente dans le DSE. La recherche de l'intitule 
type moyen n'est pas aussi representee. 



Tableau 5.5 — Donnees de interface utilisateur du cas d'utilisation 5 



Donnees affichees 


Donnees saisies 


- Code et intitule du type de moyen a traiter 


- DS et type de moyen a traiter 


- Date de I'arbitrage 


- Date d'arbitrage 

- Code validation 



InterfaceUtilisateur 



-nom 

-prenom 

-id 



+saisirArbitrage() 
+demanderChoisirTyperroyen() 
+demanderSaisirArbitrage() 
+validerArbitrage() 



Cadrage-DS 



-typeMoyenC 
•cadrageA 
•date arbitrage 



+afficherArbitrage() 
+validerArbitrage() 
+rrodifierArbitrage() 



TypeMoyen 



■typemoyen 
■inttuleTypemoyen 



Figure 5.22 — 



Diagramme de classe du cas d'utilisation 5 
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Cas d'utilisation 6- « Notifier les moyens arbitres » 

Description textuelle du cas d'utilisation 

• Objectif - Permettre au DS de produire les lettres informant les directeurs 
d'unite des moyens qui leur sont alloues. 

• Acteur concerne - DS. 

• Pre condition - Aucune. 

• Scenario nominal 

1 Le DS demande Pextraction du fichier pour Pedition des lettres type d'attri- 
bution de moyens. 

2 Le systeme genere le fichier des lettres de notification. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.23), Pelaboration de Pinterface utilisateur (tab. 5.6) et Pelabora- 
tion du diagramme de classe (fig. 5.24). 




: InterfaceUtilisateur 




: DS 




: Unite 




: Attributions 

















loop J 

notifierMcjye ns(DS]) 



toutes les unites du DS 



notifierMoyensQ 



extra ireAttributionNftypemoyen 



attributions d'une uniti> ttributions d ' une unit <? 
)utes les unfces ! 



Figure 5.23 — Diagramme de sequence du cas d'utilisation 6 
Tableau 5.6 — Donnees de I'interface utilisateur du cas d'utilisation 6 



Donnees affichees 


Donnees saisies 


- Code et intitule du DS 


- Code du DS 


Pour chaque unite concernee : 

- Code 

- Intitule 

- Adresse 

- Nom du directeur 




- Type moyen et nombre correspondant au 
moyen attribue (pour toutes les attributions). 
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InterfaceUtilisateur 



-nom 

-prenom 

-id 



+demanderNotifierMoyens() 



-numAttrib 
-dateAttrib 



+extraireAttributionN() 



Attributions- RH 



-gradeA 
-nombreA 



Attribution-RF 



■typeMoyensA 
■montantA 



Unite 



-code unite 
-intitule unite 
-nom directeur 
-adresse rue 
-adresse ville 
-adresse code postal 



+notifierMoyens() 



+codeDS 
+intituleDS 



+notifierMoyens() 



Figure 5.24 — Diagramme de classe du cas d'utilisation 6 

Cas d'utilisation 7- « Choisir un type de moyen » 

Description textuelle du cas d'utilisation 

• Objectif - Permettre aux acteurs de choisir le type de moyen qu'ils veulent 
traiter. 

• Acteurs concernes - Instructeur DS ou DG ou coordonnateur. 

• Pre condition - RAS. 

• Scenario nominal 

1 Le systeme affiche la liste des types de moyen. 

2 L'acteur concerne choisit le type de moyen qu'il veut traiter. 

• Scenarios alternatifs - Aucun. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.25), Pelaboration de l'interface utilisateur (tab. 5.7) et Pelabora- 
tion du diagramme de classe (fig. 5.26). 



InterfaceUtilisateur 



Utilisateur 



demanderChoisirTypemoyenQ 



K- 



liste des types de moyen 
choisirUntypemoyen(typennoyen) 



: Cadraqe-DS 



3} 



listerTypemoyensQ, 



Tl 



Figure 5.25 — 



Diagramme de sequence du cas d'utilisation 7 
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Tableau 5.7 — 



Chapitre 5. Etude de cas n° I Analyse 

Donnees de I'interface utilisateur du cas d'utilisation 7 



Donnees affichees 


Donnees saisies 


- Liste des types de moyen proposes 


- Code du type de moyen choisi 



InterfaceUtilisateur 



■prenom 
■id 



+demanderChoisirTypemoyen() 
+choisirUntypemoyen() 



Cadraqe-DS 




-DStypeMoyenC 
-cadrageA 
-date cad rage 






cadrer 


TypeMoyen 


-typemoyen 
-intituleTypemoyen 


+listerTypemoyens() 


1. * 1 









Figure 5.26 — Diagramme de classe du cas d'utilisation 7 



Cas d'utilisation 8 « Suivre I'avancement des attributions » 
Description textuelle du cas d'utilisation 

• Objectif - Mettre a la disposition des departements scientifiques un ensemble 
de tableaux de suivi des attributions des moyens aux unites. 

• Acteur concerne - Coordonnateur. 

• Pre condition - Etre a l'interieur de l'execution du cas d'utilisation n° 4 : 
Gerer les moyens arbitres. 

• Scenario nominal 

1 Le systeme affiche la liste des tableaux de suivi. 

2 Le coordonnateur saisit le choix correspondant au tableau souhaite. 

3 Le systeme produit le tableau de suivi demande. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 5.27), Pelaboration de I'interface utilisateur (tab. 5.8) et Pelabora- 
tion du diagramme de classe (fig. 5.28). 



5.5 SYNTHESE DE L ANALYSE 



Le diagramme de classe recapitulatif (FG13) de la figure 5.29 integre Pensemble des 
diagrammes de classe elabores par cas d'utilisation. 
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% 

: DS 



InterfaceUtilisateur 



DS 



Cadraqe-DS 



Unite 



Attributions 



7aemanderTableauxdesuivi(typemoyen, DS) I ■ 

E 'U 

afficfier le choix des tableaux de siiivi ; | 

construireTableaudesuivi(DS, typemoyen) 
-*r*i extraireCadra g eQ 




i Toutes les unites du DS 

construireTableaudesuivi(typemoyen^ donnerAttr| ^i 0n() 



ons de: 



attributibns d'une unite 



toutes I as unites 



Figure 5.27 — Diagramme de sequence du cas d'utilisation 8 



Tableau 5.8 — Donnees de I'interface utilisateur du cas d'utilisation 8 



Donnees affichees 


Donnees saisies 


- Liste des tableaux de suivi 


- Choix du tableau de suivi 



Attributions 



-numAttrib 
-dateAttrib 



+donnerAttribution() 



Interf aceUti I isateu r 



-nom 

-Drenom 

-id 



+demanderTableauxdesuivi() 
+choisirUntableaudesuivi() 



0..* 



allouer 
1 



Unite 



-code unite 
-intitule unite 
-nom directeur 
-adresse rue 
-adresse ville 
-adresse code postal 



+construireTableaudesuivi() 



Cadrage-DS 



■DStypeMoyenC 
■cadrageA 
■date arbitrage 



+extraireCadrage() 



[ fixer 



rattacher 



DS 



■codeDS 
■intituleDS 



+construireTableaudesuivi() 



Figure 5.28 — 
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Etude de cas n° 2 
Analyse et conception 



6.1 ENONCE DU CAS GESTION ACTIVITE ET FRAIS 

La societe JeConseille, specialised dans le conseil et Paudit aupres de petites et 
grandes entreprises, souhaite automatiser son systeme de reporting d'activite et de 
frais. Elle desire que son nouveau systeme soit accessible par tous ses employes lors de 
leurs missions. Des niveaux de performances sont exiges : 100 connexions simulta- 
nees et les temps de reponse pour chaque ecran ne doivent pas depasser 5 secondes. 

Le fonctionnement actuel du systeme repose sur la saisie dans un tableur, par les 
employes, de rapports previsionnels d'activite et de frais mensuels. Ces rapports con- 
tiennent le nombre de jours travailles previsionnels dans le mois, la repartition par 
projet (nombre de jours/par projet), le trajet previsionnel realise durant le mois (km) 
et un cumul des frais (€) previsionnel depense durant le mois. 

Ces rapports previsionnels sont envoyes a la secretaire de la division en debut de 
mois par messagerie. La secretaire relance via la messagerie les employes n'ayant pas 
fourni leurs rapports. 

La secretaire effectue par la suite une consolidation par division de tous les rap- 
ports previsionnels afin d'obtenir une synthese des activites, des frais par projet et le 
taux d'activite de la division. 

Cette synthese est consultee par le manager de la division tous les mois. 

Une modification de l'activite ou des frais d'un consultant fait l'objet d'une 
modification du rapport enregistre et d'un nouvel envoi de mail a la secretaire. 

En fin de mois, la secretaire reporte manuellement les informations necessaires sur 
les activites et les frais des employes dans le systeme de facturation de l'entreprise. 
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Les fonctionnalites attendues sont decrites dans l'etape d'expression des besoins 
de la demarche UML. 



6.2 MODELISATION METIER 

6.2.1 Elaboration du schema de contexte du domaine d etude (FG1) 

Le schema de contexte du cas « Gestion activite et frais » est presente a la figure 6. 1 . 











Gestion des frais 






et des activites 











Facturation 



Figure 6.1 — Representation du schema de contexte 

Deux sous-ensembles et leurs dependances sont modelises dans ce diagramme : 

• Gestion des frais et des activites - Le sous-ensemble etudie tout au long de 
l'etude de cas. 

• Facturation - Le sous-ensemble connexe dans lequel chaque mois sont trans- 
mises les donnees des activites et des frais pour etablir la facturation de 
l'entreprise. 



6.2.2 Elaboration du diagramme d'activite (FG2) 

Le diagramme d'activite est donne a la figure 6.2. 



6.2 Modelisation metier 
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Manager 



Employe 



Secretaire 



Facturation 



c 



Gerer frais 



Piloter activite 
et frais 



D 



Gerer activiti 



TFrais 
qeresl 



< Relancer | 
activite J 



^ 


/ 


TActivite 
relanceel 



TActivite 
qereel 



Communiquer activiteN 
et frais y 



TActivite 
communiqueel 



TFrais 
communiques" 



Figure 6.2 — Diagramme d'activite 



Quatre acteurs sont identifies : 

• Employe - II gere son activite et ses frais chaque mois (creation, modification, 
consultation). 

• Secretaire - II ou elle 1 relance les employes n'ayant pas cree leur activite. Elle 
communique l'activite et les frais des employes au systeme de facturation en 
fin de mois. 

• Manager - II peut piloter l'activite et les frais de ses employes. 

• Facturation - Cette entite correspond au systeme de facturation de l'entre- 
prise qui regoit les activites et frais des employes en fin de mois. 

6.2.3 Elaboration du diagramme de classe metier (FG3) 

Le diagramme de classe metier est donne a la figure 6.3. 



1. Par simplification d'ecriture et en considerant le cas traite, nous avons pris l'hypothese que le 
poste de secretaire est occupe par une femme. 
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Profil 



+libelle 



Utilisateur 



+nom 

+prenom 

+identifiant 



realise 



Activite 



+charge 



correspond 



Date 



+]Our 
+mois 
+annee 




Division 



+libelle 



engage 



Frais 



+montant 



se rapporte 



se rapporte 



Projet 



+code projet 
+libelle 



correspond 



Figure 6.3 — Diagramme de classe metier 



Definition des concepts du domaine (glossaire metier) 

• Utilisateur - Ce concept englobe tous les acteurs utilisant l'application. 

• Profil - Les utilisateurs appartiennent a differents profils (employe, secretaire, 
manager) qui ont des habilitations differentes sur l'application. 

• Division - L'entreprise est structured en plusieurs divisions, chacune ayant sa 
specificite (marketing, comptabilite...). 

• Activite - Ce concept correspond a la quantite de travail fournie par chaque 
employe de l'entreprise. 

• Frais - Ce concept correspond aux differentes depenses survenues pour 
chaque employe dans le cadre de son activite. 

• Projet - Ce concept correspond au moyen de mettre en ceuvre l'activite des 
employes au sein de l'entreprise. 

• Date - Ce concept permet d'archiver l'activite et les frais des employes de 
l'entreprise. 

Les concepts metiers decrits sont illustres sur les figures 6.4 et 6.5. II s'agit des for- 
mulaires utilises avant informatisation : le releve mensuel d'activite et le releve 
mensuel de frais. 
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6.3 EXIGENCES FONCTIONNELLES 



6.3.1 Elaboration du diagramme des cas d'utilisation systeme (FG4) 

A partir du diagramme d' activite et de la connaissance des besoins des acteurs, nous 
elaborons une vision generate des cas d'utilisation metiers du futur systeme (fig. 6.6). 



Employe 



Secretaire - 



Manager 



System 




^Relancer activit^) 




<<Systeme externe>> 
Service Facturation 



Figure 6.6 — Diagramme des cas d'utilisation systeme 



Description generate des cas d'utilisation metiers 

• Cas d'utilisation 1- « Gerer activite » - L'employe renseigne son activite en 
debut de mois pour les projets sur lesquels il va travailler. La description de 
Pactivite est realisee par journee. La secretaire peut ainsi retrouver, pour une 
journee donnee, l'activite realisee par l'employe. 

Un recapitulatif de son activite sur le mois en cours ou sur les mois precedents 
est propose a l'employe. Si l'employe ne peut renseigner son activite (maladie, 
absence), la secretaire est habilitee a renseigner son activite. 

• Cas d'utilisation 2- « Gerer frais » - L'employe renseigne ses frais prevision- 
nels (frais kilometriques, frais divers) en debut de mois pour les projets sur 
lesquels il va travailler. 

La description des frais est realisee par journee. La secretaire peut ainsi retrou- 
ver pour une journee donnee, les frais previsionnels d'un employe. 
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Un recapitulatif de ses frais sur le mois en cours ou sur les mois precedents est 
propose a l'employe. Si l'employe ne peut renseigner ses frais pour cause de 
maladie ou absence, la secretaire est habilitee a renseigner ses frais. 

• Cas d'utilisation 3- « Relancer activite » - La secretaire relance par message - 
rie, a partir du 10 de chaque mois, les employes n'ayant pas ou partiellement 
renseigne leurs activites mensuelles. Si la secretaire ne peut relancer l'activite, 
le manager est habilite a le faire a sa place. 

• Cas d'utilisation 4- « Consulter tableaux de bord » - Le manager visualise 
des tableaux de bord sur l'activite, les frais, et le taux d'activite pour un projet 
donne ou une division donnee et sur une periode donnee. 

• Cas d'utilisation 5- « Exporter activites et frais » — A la fin de chaque mois, 
la secretaire exporte les activites et les frais de tous les employes vers le service 
facturation. Si la secretaire ne peut exporter les activites et les frais, le mana- 
ger est habilite a le faire a sa place. 



6.3.2 Elaboration des diagi amines de sequence systeme (FG5) 

Chaque cas d'utilisation decrit ci-dessus donne lieu a un diagramme de sequence 
systeme : 

• DSE du CU Gerer activites (fig. 6.7) 

• DSE du CU Gerer frais (fig. 6.8) 

• DSE du CU Consulter tableaux de bord (fig. 6.9) 

• DSE du CU Exporter activites et frais (fig. 6.10) 

• DSE du CU Relancer activite (fig. 6.11) 




<< system >> 
Gestion des frais 
et activites 



: Employe 



loop 




saisirActivite(charge,code projet,jour,mois,annee) 



activite saisie 




consulterActivite(mois) 




< 



activites 



Figure 6.7 — 



DSE du CU Gerer activites 
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<<system>> 
Gestion des frais et activities 



Employe 



loop J 



saisirFrais(montant,code projet,jour,mois,annee) 



frais saisis 



consulterFrais(mois) 



frais 



H 



Pour toutes 

les activites avec frais 



Figure 6.8 — DSE du CU Gerer frais 



Manager 



<< system >> 
5estion des frais et activites 



alt 



consulterTableaux(pro]et,mdebutPeriode,adebutPeriode,mfinPeriode, afinPeriode) 



[debUtPeriode = finPeriode 1 1 debutPeriode > finPeriode] 



periode mal renseignee 



[peridde OK] 

l< 



tableaux de bord 



Debut de periode identique 

a fin de periode 

ou 

debut de periode plus recente 
que la fin de periode 



Figure 6.9 — 



DSE du CU Consulter tableaux de bord 
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« system >> 
Gestion des frais et activities 



: Secretaire 



exporterActiviteFraisQ 



<<Systeme externe>> 
: Service facturation 



A la fin de chaque mois 



importerActiviteFraisQ 



Figure 6.10 — DSE du CU Exporter activites et frais 



o 

X 



<<system>> 
Gestion des frais et activites 



Secretaire 



relancerActiviteQ 



A partir du 10 de chaque mois 



5 



activite relancee 



Figure 6.11 — DSE du CU Relancer activite 



6.3.3 Elaboration du schema de navigation generale (FG6) 

Dans le cadre de l'expression des exigences fonctionnelles, l'enchaTnement des 
futurs ecrans de Papplication avec les habilitations des differents acteurs est presente 
sur la figure 6.12. 
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Accueil 



[ secretaire ou manager ] 



Tableaux de bord 



[ manager ] 



Exportation activite et frais 



[ secretaire ou manager ] 
54 



Relance activite 



[ employe ou secretaire ] 

?4 



Consultation frais 



[ employe ou secretaire 



Saisie frais 



[ employe ou secretaire ] 



Consultation activite 



[ employe ou secretaire ] 



Saisie activite 



Figure 6.12 — Schema de navigation generale 



6.4 ANALYSE DES CAS D'UTILISATION 

6.4.1 Elaboration du diagi amine des cas d'utilisation (FG7) 

Ce diagramme de cas d'utilisation (fig. 6.13) est plus detaille que celui presente au para- 
graphe precedent. En effet, nous sommes passes dans une phase d'analyse qui corres- 
pond a une vue informatique du systeme et nous avons identifie 13 cas d'utilisation. 
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Administrate 



<<Systeme externe>> 
Service facturation 



^^Crder utilisa^eur^^ 



^Modifier utih^ateur) 




Figure 6.13 — Diagramme des cas d'utilisation 



6.4.2 Description des cas d'utilisation (FG8, FG9, FG11, FG12) 

Pour la suite de l'etude de cas, nous allons poursuivre l'analyse sur les cinq cas 
d'utilisation suivants seulement : 

• Saisir activite 

• Consulter activite 

• Relancer activite 



6.4 Analyse des cas d'utilisation 
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• Consulter tableaux de bord 

• Creer utilisateur 

Pour chaque cas d'utilisation, les sous-activites suivantes de l'activite « Analyse 
des cas d'utilisation » sont realisees : 

• Description du cas d'utilisation (FG8) 

• Elaboration du diagramme de sequence (FG9) 

• Elaboration de l'interface utilisateur (FG1 1 ) 

• Elaboration du diagramme de classe (FG12) 

Les scenarios alternatifs des cas d'utilisation ont ete modelises uniquement sur le 
cas d'utilisation « Relancer activite ». 

Cas d'utilisation « Saisir Activite » 

Description textuelle du cas d'utilisation 

• Objectif - Saisir l'activite mensuelle de l'employe. 

• Acteur concerne - L'employe. 

• Pre condition - L'employe s'est authentifie correctement a l'application 

• Scenario nominal 

1 L'application propose la saisie de la premiere semaine du mois en cours. 

2 L'employe selectionne un ou plusieurs projets correspondant a l'activite de 
la semaine, puis saisit la charge consommee estimee sur chaque projet. Cette 
charge consommee est indiquee en jour. 

3 L'employe valide l'activite de la semaine. 

4 L'employe repete les actions 1 a 3 pour toutes les semaines du mois a traiter. 

• Scenario alternatif 

2a L'employe saisit une charge negative pour un projet pour une journee don- 
nee. 

- L'employe saisit une charge negative pour un projet sur une journee donnee. 

- L'employe valide l'activite de la semaine. 

- L'application avertit l'employe qu'une charge negative a ete saisie. 

- Le cas d'utilisation reprend au point 2. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 6.14), Pelaboration de l'interface utilisateur (fig. 6.15) et Pelabora- 
tion du diagramme de classe (fig. 6.16). 
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: Utilisateur 




: Activite 




: Proiet 




: Date 























: Employe 



loop ) 

saisirActivite(charge, code projet, jobr, mois, annee) 



<<create>> 
Activite(^h^rg e, code projet, w ur, mois, annee) 



0* 



checkActivitePositive(charge) 



getProjet(code projet) 



D 



projet 

getDate(joui-j mois, annee) 



date 



pour toutes 

les activites de la semaine 



Figure 6.14 — Diagramme de sequence du CU Saisir activite 



Saisir activite fevrier 



S 1 


S2 


S3 


S4 



Lundi Mardi Mercredi Jeudi Vendredi Samedi Dimanche 



Code projet 2 



Code projet 1 0.5 0.5 1 

0.5 0.5 



Ajouter un code 



4j 
1 j 

Total : 5j 



Valider 



Figure 6.15 — Ecran Saisir Activite 
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Date 



-jour 
-mois, 
-annee 



+getDate(jour, mois, annee) 



Utilisateur 



-nom 
-prenom 
-identifiant 
-mot de passe 



+saisirActivite(charge, code projet, jour, mois, annee) 



realise 



1 1..* 



correspond 



Activite 



-charge 



+Activite(charge, code projet, jour, mois, annee) 
+checkActivitePositive(charge) 



se rapporte 



Projet 



-code projet 
-libelle 



Figure 6.16 — Diagramme de classe du CU Saisir activite 



Cas d'utilisation « Consulter activite » 

Description textuelle du cas d'utilisation 

• Objectif - Pour un employe donne, avoir un recapitulatif de l'activite sur le 
mois en cours ou sur les mois precedents. 

• Acteur concerne - L'employe. 

• Pre condition - L'employe s'est authentifie correctement a l'application. 

• Scenario nominal 

1 L'employe selectionne un mois. 

2 L'application presente l'activite mensuelle de l'employe avec la repartition 
entre les differents projets (si l'employe a participe a plusieurs projets au 
cours du mois). 

3 L'application fait aussi un cumul global de l'activite mensuelle de l'employe, 
puis des cumuls mensuels de l'activite par projet. 

• Scenario alternatif 

2a : L'application ne peut presenter l'activite car elle n'a pas ete encore saisie 
pour le mois selectionne. 

- L'application affiche un message indiquant qu'il n'y a pas d'activite pour 
le mois selectionne. 

- L'employe revient sur la selection du mois. Le cas d'utilisation reprend au 
point 1. 
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Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 6.17), Pelaboration de l'interface utilisateur (fig. 6.18), et Pelabo- 
ration du diagramme de classe (fig. 6.19). 



Utilisateur 



: Activite 



Date 



Employe 



qetActivitesdnois) 



loop J 



checkActiviteMois(rhois) 



getDateQ 



compareriyiois(mois) 



activites 

ca leu ITota I MoisActivite( mois): 
' 



cumul activite 



1 



Pour toutes les activites enregistrees 
la methode getActivites ne renvoie 
que les activites du mois selectionne 



Traitement identique a celui de getActivites(mois) 
avec en plus un cumul des charges. 



Figure 6.17 — Diagramme de sequence du CU Consulter activite 
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Consulter activite 

Selectionner un mois pour afficher le recapitulatif de votre activite : 



Mois : 



Mois 



Valider 



Consulter activite fevrier 

L1 M2 M3 J4 V5 S5 D6 L7 M8 M9 J10 V1 1 S12 D13 L14 M15 M16 J17 V18 S19 D20 L21 M22 M23 J24 V25 S26 D27 L28 
CP1 111 1 1 

CP2 11111 11111 11111 1 



Total : 21 j 



Figure 6.18 — Ecran Consulter selection activite 



Date 

-jour 
-mois 
-annee 

+getDate(jour, mois, annee) 
+comparerMois(mois) 



1 



Utilisateur 



-nom 
-prenom 
-identifiant 
-mot de passe 



+saisirActivite(charge, code projet, jour, mois, annee) 
-t-getActivites(mois) 
+calculTotalMoisActivite(mois) 
+checkActiviteMois(mois) 



realise 



correspc id 



-charge 



+Activite(charge, code projet, jour, mois, annee) 
+getDate() 

+checkActivitePositive(charge) 



Figure 6.19 — 



Diagramme de classe du CU Consulter activite 
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Cas d'utilisation « Relancer activite » 

Description textuelle du cas d'utilisation 

• Objectif - Relancer, a partir du 10 de chaque mois, les employes n'ayant pas 
saisi leur activite du mois. 

• Acteur concerne - La secretaire. 

• Pre condition - La secretaire s'est authentifiee correctement a Papplication. 

• Scenario nominal 

1 L' application presente la liste des employes qui n'ont pas saisi (ou partiel- 
lement) leur activite mensuelle. 

2 La secretaire valide cette liste. 

3 L' application envoie un courriel de relance aux employes concerned. 

• Scenarios alternatifs 

la Relance effectuee avant le 10 du mois en cours. 

- L' application affiche un message indiquant que la relance ne peut avoir 
lieu qu'a partir du 10 du mois. Le cas d'utilisation se termine en echec. 

lb Tous les employes ont rempli leur activite. 

- L' application affiche un message indiquant que tous les employes ont saisi 
leur activite. Le cas d'utilisation se termine en echec. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par l'elaboration de diagrammes 
de sequence (fig. 6.20 et 6.21), l'elaboration de Pinterface utilisateur (fig. 6.22), et 
l'elaboration du diagramme de classe (fig. 6.23). 
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Utilisateur 



Secretaire 



getUtilisateursRelance() 
fri 



Verification que le jour du mois ^ 
courant est > 10 



loop J 



checkDateMois() 
checkAIIActiviteCompleteO 



Verification que tous les utilisateurs 
ont saisi leur activite 



5 



0 



isActiviteComplete(mois) 



utilisateursARelancer 
en yoiMailUtilisateurs(listU ^ Niia teurs) 



Pour chaque utilisateur, on regarde si I'activite est 
complete pour le mois en cours. Si le retour de 
cette methode est faux, il est ajoute dans les 
utilisateurs a relancer. 



loop. 



getMail() 



envoiMail(mail) 



IT 



Pour tous les utilisateurs a relancer, 
un mail de relance est envoye. 



Figure 6.20 — Diagramme de sequence du CU Relancer activite 
(scenario nominal) 



Sur le meme DSE (fig. 6.21) sont represented le scenario alternatif « la Relance 
effectuee avant le 10 du mois en cours » et le scenario alternatif « lb Tous les em- 
ployes ont rempli leur activite ». 
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Utilisateur 



Secretaire 



getUtilisateursRelance() 



Verification que le jour 
du mois courant est > 10 



checkDateMoisQ 



It 



erreur jour du mois courant < 10; 
getlltilisateursRelanceQ 



Jour du mois courant 



checkDateMois() 



checkAIIActiviteCompleteQ 



Verification que tous les utilisateufei 
ont saisi leur activite 



Tous les utilisateurs K 
de I'application ont saisi 
leur activite 



Figure 6.21 — Diagramme de sequence du CU Relancer activite 
(scenarios alternatifs) 
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Relancer activite fevrier 



La liste des employes a relancer : 

• Jean Dupont 

• Michel Durand 

• Pierre Martin 

• Joel Bernard 

• Marc Richard 

• Romain Dubois 

• Michael Simon 

• Deborah Robert 

• Laura Fournier 

• Julia Roux 



Relancer 



Figure 6.22 — Ecran Relancer activite 



Utilisateur 


-nom 




-prenom 




-identifiant 




-mot de passe 




-mail 





+saisirActivite(charge, code projet, jour, mois, annee) 

+getActivites(mois) 

-t-checkActiviteMois(mois) 

+calculTotalMoisActivite(mois) 

+checkDateMois() 

+getUtilisateursRelance() 

+isActiviteComplete(mois) 

+checkAIIActiviteComplete() 

+envoiMailUtilisateurs(listUtilisateurs) 

+getMail() 

+envoiMail(mail) 



Figure 6.23 — Diagramme de classe du CU Relancer activite 

Cas d'utilisation « Consulter tableaux de bord » 

Description textuelle du cas d'utilisation 

• Objectif - Fournir au manager des tableaux de bord sur l'activite, les frais, le 
taux d'activite pour un projet donne ou une division donnee et sur une 
periode donnee. 

• Acteur concerne - Le manager. 

• Pre condition - Le manager s'est authentifie correctement a l'application. 
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• Scenario nominal 

1 Le manager selectionne une periode (mois, annee). 

2 L' application propose des tableaux de bord sur la periode et la division du mana- 
ger concernant l'activite par projet (nombre de jours/h par projet), le taux d'acti- 
vite (nombre de jour/h sur un projet / nombre de jour/h total de la periode). 

3 L' application propose aussi un affichage de graphiques. 

• Scenarios alternatifs 

la Le manager selectionne une periode erronee (date debut de periode est 
superieure a la date de fin de periode ou date de debut de periode est iden- 
tique a la date de fin de periode). 

- L' application presente un message d'erreur sur la periode selectionnee non 
valide au manager. Le cas d'utilisation reprend au point 1 . 

2a Aucun employe n'a rempli son activite et ses frais sur la periode selec- 
tionnee. 

- L' application affiche un message indiquant qu'aucun employe n'a saisi son 
activite ou ses frais. Le cas d'utilisation se termine en echec. 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par l'elaboration de l'elaboration 
du diagramme de sequence (fig. 6.24), l'elaboration de l'interface utilisateur 
(fig. 6.25, fig. 6.26), et l'elaboration du diagramme de classe (fig. 6.27). 

Par simplification, Paffichage des graphiques n'est pas traite sur le DSE figure 6.24 
ni dans le reste de l'etude de cas. 
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: Manager 



: Proiet 




: Utilisateur 




: Activite 




: Division 




: Date 































calculNbJoursPrcjjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) 

getUtilisateurQdefltifjant) 



Pour tons les projets 1 



Si le projet appartient 
a la meme division 
que le manager 



Pour toutes les activities 
du projet 



Un cumul des charged 
par projet est retourne 



loop ) 

* isProie 



isProje-t meDilisionfcode division) 



opt 



loo| 



getUtihsateur(ideritifaan 



getDivision() 



■"H getCodeDivision() 



Ai meDil/i 



qeEDateQ 



Une somme de toutes les chargfe 
par projet est realisee 
si le projet appartient 
a la periode selectionnee 



isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) 



opt 



get£harge() 



calculTauxActivjteCmoisDebut, anneeDebut, moisFin, ahneeFin, identifiant) 



calculNbJoursTotalProjet( nc 



Meme traitement que CalculNbJousProjet 1 
mais un cumul total des charges des projets 
est retourne 



Le taux d'activite correspond au ratio 1 
entre le resultat de calculNbProjet 
et de calculNbJoursTotalPeriode * 100 



sDeblit, anneeDebut, 



'eri id i(moi{Debut, anneeDebut, moisFin, anneeFin) 

nbJourpDansPeriode(moisDebut, AnneeDebut, moisFin, pnneeFin) 



moisFin, anneeFin, identifiant) 



D 



Figure 6.24 — 



Diagramme de sequence du CU Consulter tableaux 



de bord 
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Selection tableaux de bord 



Selectionner une periode pour afficher les tableaux de bord pour la division Industrie : 
Debut periode : 



Mois 



Annee 



Fin periode : 



Mois 



4J. Annee JJ, 



Valider 



Figure 6.25 — Ecran Selection tableaux de bord 



La liste des projets et leurs activites pour la division Industrie sur la periode novembre/decembre (effectif total : 
10 personnes, duree de la periode : 40 j) : 



Projet 


Activite (j/h) 


Code projet 1 


100 


Code projet 2 


80 


Code projet 3 


80 


Code projet 4 


30 


Code projet 5 


70 



Taux d'activite de la division Industrie pour la periode novembre/decembre : 



Periode 


Taux d'activite de la division (%) 


N ove m bre/d ecem b re 


90 



graphiques 



Figure 6.26 — Ecran Consulter tableaux de bord 
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+getDate(jour, mois, annee) 
+comparerMois(mois) 

+isDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) 
+nbJoursDansPeriode(moisDebut, anneeDebut, moisFin, anneeFin) 



-nom 
-prenom 
-identifiant 
-mot de passe 
-mail 



+saisirActivite(charge, code projet, jour, mois, annee) 

+getActivites(mois) 

+calculTotalMoisActivite(mois) 

+getUti I isateu rsRela nce( ) 

+isActiviteComplete(mois) 

+checkDateMois() 

+checkAIIActiviteComplete() 

+envoiMailUtilisateurs(listUtilisateurs) 

+getMail() 

+envoiMail(mail) 

+getUtil isateu r( identifiant) 

+getDivision() 



a ipartient 



correspond 



-charge 



+Activite(charge, code projet, jour, mois, annee) 

+modifier(charge) 

+getDate() 

+getCharge() 

+checkActivitePositive(charge) 



-code division 
-libelle 



+getCodeDivision() 



se 'apporte 



Projet 



-code projet 
-libelle 



+getProjet(code projet) 
+isProjetMemeDivision(code division) 

+calculTauxActivite(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) 
+calculNbJoursProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) 
+calculNbjoursTotalPeriode(moisDebut, anneeDebut, moisFin, anneeFin) 
+calculNbJoursTotalProjet(moisDebut, anneeDebut, moisFin, anneeFin, identifiant) 



Figure 6.27 — Diagramme de classe du CU Consulter tableaux de bord 
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Cas d'utilisation « Creer utilisateur » 

Description textuelle du cas d'utilisation 

• Objectif - Initialiser l'application avec les utilisateurs. 

• Acteur concerne - Administrateur. 

• Pre condition - L'administrateur s'est authentifie correctement a l'application. 

• Scenario nominal 

1 L'administrateur cree un utilisateur avec ses caracteristiques : prenom, nom, 
mail, profil. 

2 L'application enregistre les informations renseignees et affiche un message 
de confirmation. 

3 Un mail est envoye a l'utilisateur cree avec son identifiant/password. 

• Scenarios alternatifs 

la L'administrateur saisit un nom ou un prenom avec des chiffres. 

- L'application affiche un message d'erreur precisant que le nom ou prenom 
sont des chaines de caracteres uniquement. Le cas d'utilisation reprend au 
point 1. 

lb L'administrateur saisit un nom ou prenom superieur a 50 caracteres. 

- L'application affiche un message d'erreur precisant que le nom ou prenom 
sont des chames de caracteres inferieures a 50 caracteres. Le cas d'utilisation 
reprend au point 1. 

lc L'administrateur saisit un mail errone (controle sur le @). 

- L'application affiche un message d'erreur precisant que le mail n'est pas 
valide. Le cas d'utilisation reprend au point 1 . 

Description des diagrammes d'analyse du cas d'utilisation 

La suite de l'analyse du cas d'utilisation se poursuit par Pelaboration du diagramme 
de sequence (fig. 6.28), Pelaboration de l'interface utilisateur (fig. 6.29) et Pelabora- 
tion du diagramme de classe (fig. 6.30). 
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Utilisateur 



: Administrateur 



<< create >> 
Utilisateur(nom, prenom, profil, mail) 




checkNomPrenomQ 



checkMailQ 



generateIdentifiantPassword() 



envoiMail(mail) 



Mail destine a I'utilisateur 1 - 
nouvellement cree 
qui contient son identifiant 
+ password 



Figure 6.28 — Diagramme de sequence du CU Creer utilisateur 



Creer utilisateur 

Saisissez les informations relatives au nouvel utilisateur : 


Prenom : 
Norn : 
Mail : 
Profil : 










Profil {J, 


Valider 







Figure 6.29 — Ecran Creer utilisateur 
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Utilisateur 


-nom 




-prenom 




-identifiant 




-mot de passe 




-mail 




+Utilisateur(nom, prenom, profil, mail) 




+saisirActivite(charge, code projet, jour, mois, annee) 


+rechercheActivite(code projet, jour, mois, 


annee) 


+supprimerActivite(code projet, jour, mois. 


annee) 


+getActivites(mois) 




+calculTotalMoisActivite(mois) 




+getUtilisateursRelance() 




-HsActiviteComplete(mois) 




+checkDateMois() 




+checkAIIActiviteComplete() 




+envoiMailUtilisateurs(listUtilisateurs 




+getMail() 




+envoiMail(mail) 




+getUtilisateur(identifiant) 




+getDivision() 




+checkNomPrenom() 




+checkMail() 




+generateIdentifiantPassword() 





Figure 6.30 — Diagramme de classe du CU Creer Utilisateur 



6.5 SYNTHESE DE L ANALYSE 

6.5.1 Elaboration du diagramme de classe recapitulatif (FG13) 

Ce diagramme de classe (fig. 6.31) integre l'ensemble des diagrammes de classe 
elabores par cas d'utilisation. 



6.5 Synthese de /'analyse 
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6.5.2 Elaboration de la matrice de validation (FG14) 

La matrice de validation (fig. 6.32) permet de verifier que l'analyse du cas est 
complete, c'est-a-dire que tous les cas d'utilisation metier ont ete integres. Elle 
permet aussi d'etablir une correspondance entre les cas d'utilisation metier et les cas 
d'utilisation d'analyse. 



Cas d'utilisation metier 


Cas d'utilisation analyse 


Gerer activites 


Saisir activite 


Gerer activites 


Modifier activite 


Gerer activites 


Consulter activite 


Gerer frais 


Saisir frais 


Gerer frais 


Modifier frais 


Gerer frais 


Consulter frais 


Relancer activite 


Relancer activite 


Consulter tableaux de bord 


Consulter tableaux de bord 


Exporter activites et frais 


Exporter activites et frais 




Creer utilisateur 




Modifier utilisateur 




Supprimer utilisateur 




Gerer referentiel 



Figure 6.32 — Matrice de validation 



6.6 CONCEPTION 

Pour repondre aux contraintes techniques de l'entreprise JeConseille (« Elle desire 
que son nouveau systeme soit accessible par tous ses employes lors de leurs 
missions »), la conception d'un site web est necessaire. 



6.6.1 Realisation des choix techniques et elaboration des diagrammes 
techniques (FG15, FG16, FG17) 

Pour repondre aux contraintes de performances (« 100 connexions simultanees et 
les temps de reponse pour chaque ecran ne doivent pas depasser 5 secondes ») de 
Penonce de l'etude de cas, notre choix technique portera ainsi sur une architecture 
orientee service (SOA) pour la conception du site web. En effet, comme precise 
dans la presentation des architectures, les temps de reponse sont meilleurs du fait de 
l'abstraction introduite par la couche service. Le cout des appels aux objets metiers a 
partir de la couche service est tres faible. 
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Concernant, la technologie pour cette architecture, J2EE sera mise en place. 
Cette solution ne sera pas detaillee dans cet ouvrage. 

Pour chaque cas d'utilisation, les sous-activites suivantes de Pactivite 
« Conception » sont realisees : 

• elaboration du diagramme de sequence technique (FG16), 

• elaboration du diagramme de classe technique (FG17). 

Cas d'utilisation « Saisir activite » 

L'elaboration du diagramme de sequence technique (fig. 6.33), et ^elaboration du 
diagramme de classe technique (fig. 6.34) sont realisees. 



: Dialogue Saisir Activite 



: CTRL Saisir Activite 



: Employe 




Cette methode a comme parametre 
la saisie de I'employe: 

- une liste de charges 

- une liste de dates (format date : jj/mm/a3aa) 

- une liste de code projet 



saisirActivite( charges, dates, codes projet) 



Utilisateur : Activite : Collection Projet 



J c heckActi vite Positive( charges) 
qetUtilisateurActifQ 

getldentifiantfj 



i <<create>> 
Activite(charge, code projet, date, id ^j t ijisate u r) 



getProjet(code projet) 



Cette methode fait appel au contexte L 
de I'application pour recuperer I'utilisateu r 
actif {Session pour les applications Web) . 
Le contexte n'a pas ete modelise ici. 



Pour toutes les activites 
de la semaine 



Figure 6.33 — Diagramme de sequence technique du CU Saisir activite 



La navigabilite des associations est donnee par le sens de circulation des opera- 
tions du diagramme de sequence (fig. 6.33). Ainsi, la classe « Dialogue Saisir 
Activite » accede a la classe « CTRL Saisir Activite » par le biais du message saisi- 
r Activite. La navigabilite des autres associations est determinee sur le meme principe. 

Une relation d'agregation existe entre la classe « CollectionProjet » et « Projet » 
de type « ensemble/element », de plus une contrainte « ordered » indique que les 
projets sont tries par code projet. 
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La contrainte « ordered » entre « Utilisateur » et « Activite » exprime la rela- 
tion de tri par date croissante des « Activite » dans la collection « Utilisateur ». 





Col lection Projet 


contient {ordered} 

O 

0..* 1..* 


Projet 




+getProjet(code projet: String): String 


-code projet: String 
-libelle: String 












/ 


se rapporte 
1..* 


Utilisateur 


realise {ordered] 


Activite 


-nom: String 
-prenom: String 
-identifiant: String 
-mot de passe: String 

+getldentifiant(): String 


-charge: Float 
-date: Date 


1 1. * 


+Activite(charge: Float, code projet: String, date: Date, id utilisateur: 
+save(): void 

1 -yj 



<<Controleur>> 
CTRL Saisir Activite 



+saisirActivite(charges: List, dates: List, codes projet: List): 
+checkActivitePositive(charges: List): 
+getUtilisateurActif(): 

% 



Type Standard Date independant 
du langage de programmation 



<<Dialogue>> 
Dialogue Saisir 

-charges: List 
-codes Projet: List 

+saisirActivite(charges: List, dates: List, codes projet: List): 



Figure 6.34 — Diagramme de classe technique du CU Saisir activite 

Cas d'utilisation « Consulter Activite » 

L'elaboration du diagramme de sequence technique (fig. 6.35), et l'elaboration du 
diagramme de classe technique (fig. 6.36) sont realisees. 

La navigabilite des associations est donnee par le sens de circulation des opera- 
tions du diagramme de sequence (fig. 6.34). Ainsi, la classe « Dialogue Consulter 
Activite » accede a la classe « CTRL Consulter Activite » par le biais du message 
consulter Activite. La navigabilite des autres associations est determinee sur le meme 
principe. 
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: Dialogue Consulter Activite 



consulterActivite{mois) 



: CTRL Consulter Activite 



consulter Activrte(mois) 



getUtilisateurActiff) 



getActivites(mois) 



chec kActiviteMois(rnois) | 



compareMois(date,mois) 



calculTotalMoisActivite(mois ) 



Pour toutes les activites saisies, L 

getActivites{mois) ne renvoie 

que les activites du mois selectionne 



Traitement identique a 

celui de getActivite(mois), avec 

en plus un cumul des charges 



Le retour comprend !a liste 
des activites + le cumul 



Figure 6.35 — Diagramme de sequence technique du CU Consulter activite 



Une relation de dependance est modelisee entre la classe « Utilisateur » et la 
classe technique « DateUtils ». On remarquera que le lien entre un objet 
« Utilisateur » et « DateUtils » est momentane, il ne dure que le temps d'execution 
de la methode compareMois. Ainsi ce n'est pas une association, mais une simple 
dependance. 
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DateUtils 



+comparerMois(date: Date, mois): Boolean 











Utilisateur 






-nom: String 






Acbvitc 


-prenom: String 
-identifiant: String 
-mot de passe: String 




{ordered] 

> 


-charge: Float 
-date: Date 




1 




+getActivttes(mois: String): List 
+getldentifiant(): String 
+calculTotalMoisActivite(mois: String): Float 


+Activite(charge: Float, code projet: String, date: DateUtils, id utilisateur: String) 
+save(): void 
+getDate{): Date 


+checkActiviteMois(mois: String): Boolean 






/ 


u 
i 







<<Contr6leur>> 
CTRL Consulter Activite 



+consulterActivite(mois: String): List 
+getUtilisateurActif(): Utilisateur 

* 



<<Dialogue>> 
Dialogue Consulter Activite 

-mois: String 

+consulterActivite(mois: String): List 



Figure 6.36 — Diagramme de classe technique du CU Consulter activite 



Cas d'utilisation « Relancer activite » 

L'elaboration des diagrammes de sequence technique (fig. 6.37, fig. 6.38), et l'elabo- 
ration du diagramme de classe technique (fig. 6.39) sont realisees. 

Sur le meme DSE (fig. 6.38) sont represented le scenario alternatif « la : Relance 
effectuee avant le 10 du mois en cours » et le scenario alternatif « lb : Tous les 
employes ont rempli leur activite ». 
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: Dialoaue Erreur Relancer Activite 




: Dialoaue Relancer Activite 




: CTRL Relancer Activite 




: DateUtils 




: CollectionUti lisateu r 





















sateursRelance() 



FindUti lisateu rsRelance( ) 



rr 



checkDateMoisO 



sateursRelanceQ 



creer(messageEiTeLir)'-. 
«create>> | 



Le jour du mois courant 
est < 10 



FindUti lisateu rsRelance( ) 



rr 



creer(messageErreur) 
«create>> 



checkDateMoisO 



checkAIIActiv teComplete() 



rous les utilisateurs de N 
'application ont saisi leur activite 



Figure 6.38 — Diagramme de sequence technique du CU Relancer activite 
(scenarios alternatifs) 



La navigabilite des associations est donnee par le sens de circulation des opera- 
tions du diagramme de sequence (fig. 6.38). Ainsi, la classe « CTRL Relancer 
Activite » accede a la classe « Dialogue Erreur Relancer Activite » par le biais du 
message creer. La navigabilite des autres associations est determinee sur le meme 
principe. 
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Col lection Utilisateur 



+checkAIIActiviteComplete(): Boolean 
+getUtilisateursRelance(mois: String): List 



-nom: String 
-prenom: String 
-identifiant: String 
-mot de passe: String 
-mail: String 



+getActivites(mois: String): List 
+getldentifiant(): String 
+calculTotalMoisActivite(mois: String): Float 
+checkActiviteMois(mois: String): Boolean 
+isActiviteComplete(mois: String): Boolean 
+envoiMailUtilisateurs(listUtilisateurs: List): void 
+getMail(): String 



-dest: String 
-from: String 
-body: String 



+Mail(dest: String, from: String, body: String) 
+send(): void 



<<Controleur>> 
CTRL Relancer Activite 



+FindUtilisateursRelance(): List 
+RelancerActivite(listUtilisateurs: List): void 



+comparerMois(date: Date, mois): Boolean 
+checkDateMois(): Boolean 
+getMoisCourant(): String 



<<Dialogue>> 
Dialogue Relancer Activite 



+mois: String 



+FindUtilisateursRelance(): List 
+RelancerActivite(listUtilisateurs: List): void 



<<Dialogue» 
Dialogue Erreur Relancer Activite 



+messageErreur: String 



+creer(messageErreur) 



Figure 6.39 — Diagramme de classe technique du CU Relancer activite 

Une relation de dependance est modelisee entre la classe « Utilisateur » et la 
classe technique « Mail ». On remarquera que le lien entre un objet « Utilisateur » 
et « Mail » est momentane, il ne dure que le temps d'execution de la methode Mail 
et send. Ainsi ce n'est pas une association, mais une simple dependance. 

Cos d'utilisation « Consulter tableaux de bord » 

L'elaboration des diagrammes de sequence technique (fig. 6.40) et ^elaboration du 
diagramme de classe technique (fig. 6.41) sont realisees. 
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La navigabilite des associations est donnee par le sens de circulation des opera- 
tions du diagramme de sequence precedent. Ainsi, la classe « Dialogue Consulter 
TDB » accede a la classe « CTRL Consulter TDB » par le biais du message consulter- 
TDB. La navigabilite des autres associations est determinee sur le meme principe. 

Une relation de dependance est modelisee entre la classe « Projet » et la classe 
technique « DateUtils ». On remarquera que le lien entre un objet « Projet » et 
« DateUtils » est momentane, il ne dure que le temps d'execution de la methode 
isDansPeriode. Ainsi ce n'est pas une association, mais une simple dependance. 

Cas d'utilisation « Creer utilisateur » 

L'elaboration des diagrammes de sequence technique (fig. 6.42), et Pelaboration du 
diagramme de classe technique (fig. 6.43) sont realisees. 



: Administrateur 




: CollectionUtilisateur 



Mail destine a I'utilisateuA 
nouvellement cree 
qui contient son idenbfiant 
+ password 



Figure 6.42 — Diagramme de sequence technique du CU Creer utilisateur 



La navigabilite des associations est donnee par le sens de circulation des opera- 
tions du diagramme de sequence precedent. Ainsi, la classe « Dialogue Creer 
Utilisateur » accede a la classe « CTRL Creer Utilisateur » par le biais du message 
creerUtilisateur. La navigabilite des autres associations est determinee sur le meme 
principe. 
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6.6.2 Elaboration du diagram me de paquetage (FG18) 

Tous les paquetages de l'application sont representes sur la figure 44 : 

• Dialogue - Paquetage regroupant l'ensemble des classes permettant la gestion 
des dialogues de l'application : 

- Dialogue Saisir Activite. 

- Dialogue Consulter Activite. 

- Dialogue Relancer Activite. 

- Dialogue Erreur Relancer Activite. 

- Dialogue Consulter TDB. 

- Dialogue Creer Utilisateur. 

• Controleur - Paquetage regroupant l'ensemble des classes permettant la 
gestion des controleurs de l'application : 

- CTRL Saisir Activite. 

- CTRL Consulter Activite. 

- CTRL Relancer Activite. 

- CTRL Consulter TDB. 

- CTRL Creer Utilisateur. 

• Entite - Paquetage regroupant l'ensemble des classes metiers de l'application. 
A Pinterieur de ce paquetage, une division en trois sous-paquetages est 
presente qui correspond a un decoupage fonctionnel. 

Ces trois sous-paquetages sont les suivants. 

• Gestion des utilisateurs - Paquetage regroupant l'ensemble des classes 
permettant la gestion des donnees de Putilisateur : 

- CollectionUtilisateur. 

- Utilisateur. 

• Gestion activites et frais - Paquetage regroupant l'ensemble des classes 
permettant la gestion des donnees relatives aux activites et des frais : 

- Frais. 

- Activites. 

• Gestion du referentiel - Paquetage regroupant l'ensemble des classes pouvant 
etre administrees : 

- CollectionProjet. 

- Projet. 

- Division. 

- Profil. 
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Deux paquetages techniques sont aussi representes sur le diagramme. 

• Gestion mail - Paquetage regroupant l'ensemble des classes techniques 
permettant la gestion des mails : Mail. 

• Gestion utilitaire - Paquetage regroupant l'ensemble des classes techniques 
utilitaires : DateUtils. 

Les relations « access » decrites figure 6.44 entre le paquetage Dialogue et Con- 
troleur et entre le paquetage Controleur et Entite illustrent Pindependance des cou- 
ches du modele. En effet, les classes du paquetage Dialogue ont acces a l'espace de 
nommage du paquetage Controleur, mais cet acces ne se transmet pas par transiti- 
vite. Les classes du paquetage ont acces a l'espace de nommage du paquetage Entite, 
mais cet acces ne se transmet pas par transitivite au paquetage Dialogue. 

Les relations « import » entre le paquetage Entite et GestionUtilitaire illustrent 
bien le concept de transitivite. En effet, le paquetage Controleur ayant acces a 
l'espace de nommage du paquetage Entite a lui aussi acces au paquetage Gestion uti- 
litaire. 



=1 

Gestion utilitaire 

F — 



=1 

Gestion mail 

31 



<<import>>\ 



<<import>> / 



<<access>> 
Dialogue ■> 



<<access>> 
Controleur ■> 



Entite 



<<import> >.-•"' 



Gestion activites et frai; 
7f 



Gestion utilisateur 



\<<imDort>> 
Jii 



Gestion referentiel 



Figure 6.44 — 



Diagramme de paquetage 



Annexes 



A. RECAPITULATE DES CONCEPTS D'UML 2 

A titre de synthese, il est propose dans cette annexe une liste recapitulative des 
concepts d'UML 2 presented dans cet ouvrage. 

Ce recapitulatif est donne par diagramme apres un rappel des concepts communs. 
II peut aider le lecteur a memoriser les differents concepts mis en ceuvre dans chaque 
diagramme. 

• Concepts communs a tous les diagrammes 

- stereotype, 

- mot-cle, 

- note, 

- contrainte. 

• Concepts du diagramme de classe (DCL) 

- attribut, 

- operation, 

- visibilite, 

- association, 

- navigabilite, 

- classe et classe abstraite, 

- role, 

- multiplicity, 

- dependance, 
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- agregation et composition 

- qualification, 

- generalisation et specialisation, 

- heritage. 

• Concepts du diagramme d'objet (DOB) 

- objet, 

- lien, 

- valeur d'attribut. 

• Concepts du diagramme de composant (DCP) 

- composant, 

- connecteur, 

- port, 

- interface requise, interface fournie, 

- dependance, 

- compartiment. 

• Concepts du diagramme de deploiement (DPL) 

- nceud, 

- unite de traitement ( « device » ) , 

- environnement d'execution ( « executionEnvironment » ) , 

- artefact, 

- specification de deploiement. 

• Concepts du diagramme de paquetage (DPA) 

- espace de nommage, 

- dependance de type « import » , 

- dependance de type « access », 

- dependance de type « merge » . 

• Concept du diagramme de structure composite (DSC) 

- collaboration d'instances, 

- role (dans la collaboration). 

• Diagramme des cas d'utilisation (DCU) 

- acteur, 

- interaction, 

- scenario nominal, 

- scenario alternatif, 

- pre et post condition, 

- inclusion, extension, generalisation de cas d'utilisation. 

• Concept du diagramme etat- transition (DET) 

- etat, 

- transition, 

- evenement, 

- composition d'etat (etat composite), 



- point d'entree et de sortie, 

- point de jonction, 

- point de choix, 

- etat historise. 

Concepts du diagramme d'activite (DAC) 

- action, 

- activite, 

- dot de controle, 

- dot de donnees, 

- nceud de bifurcation, 

- nceud de jonction, 

- nceud de test-decision, 

- nceud de fusion-test, 

- nceud de donnees, 

- pin d'entree et de sortie, 
-partition (couloir d'activites). 

Concepts du diagramme de sequence (DSE) 

- ligne de vie, 

- message synchrone et asynchrone, 

- fragment d'interaction, 

- operateur, 

- interaction, 

- operateur alt, 

- operateur opt, 

- operateur loop, 

- operateur par, 

- operateurs strict/weak, 

- operateur break, 

- operateurs ignore/consider, 

- operateur critical, 

- operateur negative, 

- operateur assertion, 

- operateur ref. 

Concepts du diagramme de communication (DCO) 

- role, 

- etat, 

- message. 

Concepts du diagramme global d'interaction (DGI) 

- ceux du DAC et les fragments d'interaction du DSE. 
Concepts du diagramme de temps (DTP) 

- ligne de temps, 
-etats (temporels). 
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B. RECAPITULATE DE LA DEMARCHE UP7 

Un recapitulatif des activites et des fiches guides de la demarche UP7 proposees dans 
cet ouvrage est donne dans cette annexe. 

• Liste des activites de la demarche 

- 1 - Modelisation metier 

- 2 - Exigences fonctionnelles 

- 3 - Analyse des cas d'utilisation 

- 4 - Synthese de l'analyse 

- 5 - Conception 

- 6 - Implementation 

- 7 - Test 

• Liste des fiches guides associees aux activites 

- FG 1 - Elaboration du schema de contexte du domaine d'etude 

- FG2 - Elaboration du diagramme d'activite 

- FG3 - Elaboration du diagramme de classe metier 

- FG4 - Elaboration du diagramme des cas d'utilisation systeme 

- FG5 - Elaboration des diagrammes de sequence systeme 

- FG6 - Elaboration du schema de navigation generale 

- FG7 - Elaboration du diagramme des cas d'utilisation 

- FG8 - Description des cas d'utilisation 

- FG9 - Elaboration des diagrammes de sequence 

- FG10 - Elaboration des diagrammes d'etat-transition 

- FG11 - Elaboration des interfaces utilisateur 

- FG12 - Elaboration des diagrammes de classe 

- FG13 - Elaboration du diagramme de classe recapitulatif 

- FG14 - Elaboration de la matrice de validation 

- FG15 - Realisation des choix techniques 

- FG16 - Elaboration des diagrammes de sequence technique 

- FG 1 7 - Elaboration des diagrammes de classe technique 

- FG18 - Elaboration du diagramme de paquetage 
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